Focus on code where we are doing multiplications within malloc(9). These
are not likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
Make XICS to be OPAL-aware.
Created by: Nathan Whitehorn <nwhitehorn@freebsd.org>
Submitted by: Wojciech Macek <wma@semihalf.com>
Sponsored by: FreeBSD Foundation
P1022 SATA controller may set the wrong CCR bit for a command completion.
This would previously cause an interrupt storm. Solve this by marking all
commands complete, and letting the end_transaction deal with the successes.
Causes no problems on P5020.
While here, fix a minor bug in collision detection. The Freescale SATA
controller only has 16 slots, not 32.
related series of operations without doing a lock/unlock for each byte.
Use them when reading and writing the entire set of time registers.
The original rtcin() and writertc() functions which do lock/unlock on each
byte still exist, because they are public and called by outside code.
The implementation will follow (D12723). For now, get the changes to
commit-protected files out of the way.
Approved by: secteam (gordon)
Sponsored by: Dell EMC Isilon
Differential Revision: https://reviews.freebsd.org/D13925
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
Focus on code where we are doing multiplications within malloc(9). None of
these ire likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
X-Differential revision: https://reviews.freebsd.org/D13837
New common routines were added to kern/subr_clock.c for converting between
calendrical time expressed in BCD and struct timespec. The new functions
return EINVAL on error, as expected when the clock hardware does not provide
valid time.
PR: 224813
Differential Revision: https://reviews.freebsd.org/D13731 (no reviewers)
to which it is specific, rather than in the generic AIM startup code. This
will be required to support the radix-table-based MMU introduced with POWER9.
Ths change consists of two parts.
geom_disk: deny opening a disk for writing if it's marked as
write-protected. A new disk(9) flag is added to mark write protected
disks. A possible alternative could be to add another parameter to d_open,
so that the open mode could be passed to it and the disk drivers could
make the decision internally, but the flag required less churn.
scsi_da: add a new phase of disk probing to query the all pages mode
sense page. We can determine if the disk is write protected using bit 7
of the device specific field in the mode parameter header returned by
MODE SENSE.
PR: 224037
Reviewed by: mav
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D13360
buffers into a new pmap-module function pmap_map_user_ptr() that can
be implemented by the respective modules. This is required to implement
non-segment-based AIM-ish MMU systems such as the radix-tree page tables
introduced by POWER ISA 3.0 and present on POWER9.
Reviewed by: jhibbits
- Add a per compatible configuration struct
- Not all SoC uses the same size for DMA transfert, add this into the
configuration data
- Use new timing mode for some SoC (A64 mmc)
- Auto calibrate clock for A64 mmc/emmc
- A64 mmc controller need masking of data0
- Add support for vmmc/vqmmc regulator
- Add more capabilities, r/w speed is better for eMMC
- MMC_CAP_SIGNALING_180 gives weird result so do not enable it for now.
- Add new register documented in H3/A64 user manual
Tested-On: Pine64-LTS (A64), eMMC still doesn't work
Tested-On: A64-Olinuxino (A64), sd and eMMC are working
Tested-On: NanoPi Neo Plus2 (H5), sd and eMMC are working
Tested-On: OrangePi PC2 (H5), sd only (no eMMC)
Tested-On: OrangePi One (H3), sd only (no eMMC)
Tested-On: BananaPi M2 (A31s), sd only (no eMMC)
RTC clock hardware frequently uses BCD numbers. Currently the low-level
bcd2bin() and bin2bcd() functions will KASSERT if given out-of-range BCD
values. Every RTC driver must implement its own code for validating the
unreliable data coming from the hardware to avoid a potential kernel panic.
This change introduces two new functions, clock_bcd_to_ts() and
clock_ts_to_bcd(). The former validates its inputs and returns EINVAL if any
values are out of range. The latter guarantees the returned data will be
valid BCD in a known format (4-digit years, etc).
A new bcd_clocktime structure is used with the new functions. It is similar
to the original clocktime structure, but defines the fields holding BCD
values as uint8_t (uint16_t for year), and adds a PM flag for handling hours
using AM/PM mode.
PR: 224813
Differential Revision: https://reviews.freebsd.org/D13730 (no reviewers)
6.0.0 (branches/release_60 r321788). Upstream has branched for the
6.0.0 release, which should be in about 6 weeks. Please report bugs and
regressions, so we can get them into the release.
Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.
MFC after: 3 months
using a new macro PHYS_TO_DMAP, which deliberately has the same name as the
equivalent macro on amd64. This also sets the stage for moving the direct
map to another base address.
Focus on code where we are doing multiplications within malloc(9). None of
these is likely to overflow, however the change is still useful as some
static checkers can benefit from the allocation attributes we use for
mallocarray.
This initial sweep only covers malloc(9) calls with M_NOWAIT. No good
reason but I started doing the changes before r327796 and at that time it
was convenient to make sure the sorrounding code could handle NULL values.
Since we have no control over the name, the MAKEDEV_CHECKNAME flag must be
used to return an error on an invalid (to devfs) name instead of panicing.
r305900 that originally added this feature also introduced a few other bugs:
- Proper locking not performed
- Theoretically broke the expectation that the control event buffer would
not span more than one pages, but did not update the CTASSERT that was
in place to prevent this. However, since the struct virtio_console_control
and the bulk buffer together were quite small, this could not have happened.
Also workaround an QEMU VirtIO spec violation in that it includes the NUL
terminator in the buffer length when the spec says it is not included.
PR: 223531
MFC after: 1 week
This is in contrib code but since we only have mallocarray(9) in current
we will not upstream this.
This effectively brings back r327934, which was reverted to correct the
log message.
Attaching syscon_generic earlier than BUS_PASS_DEFAULT makes it more
difficult for specific syscon drivers to attach to the syscon node and to
get ordering right. Further discussion yielded the following set of
decisions:
- Move syscon_generic to BUS_PASS_DEFAULT
- If a platform needs a syscon with different attach order or probe
behavior, it should subclass syscon_generic and match on the SoC specific
compat string
- When we come across a need for a syscon that attaches earlier but only
specifies compatible = "syscon", we should create a syscon_exclusive driver
that provides generic access but probes earlier and only matches if "syscon"
is the only compatible. Such fdt nodes do exist in the wild right now, but
we don't really use them at the moment.
Additionally:
- Any syscon provider that has needs any more complex than a spinlock solely
for syscon access and a single memory resource should subclass syscon
directly rather than attempting to subclass syscon_generic or add complexity
to it. syscon_generic's attach/detach methods may be made public should the
need arise to subclass it with additional attach/detach behavior.
We introduce aw_syscon(4) that just subclasses syscon_generic but probes
earlier to meet our requirements for if_awg and implements #2 above for this
specific situation. It currently only matches a64/a83t/h3 since these are
the only platforms that really need it at the time being.
Discussed with: ian
Reviewed by: manu, andrew, bcr (manpages, content unchanged since review)
Differential Revision: https://reviews.freebsd.org/D13793