is actually the opposite of that stated in the comment.
Remove an unnecessary assignment. Use an assertion to document the fact
that no assignment is needed.
Rewrite another comment to clarify that the page is not completely valid.
Reviewed by: kib
Do not set canmount=noauto on the boot environment at create time, because
this causes / to not be mounted, and since the chroot is read only, new
mountpoints cannot be created.
The property is set later, when other properties are adjusted
Reported by: HardenedBSD
Sponsored by: ScaleEngine Inc.
The EFSYS_PREEMPT_DISABLE() and EFSYS_PREEMPT_ENABLE() macros
were used to ensure correct timing of I2C operations. The APIs
for I2C operations have been removed, so these macros have no
callers.
Submitted by: Andy Moreton <amoreton at solarflare.com>
Sponsored by: Solarflare Communications, Inc.
MFC after: 1 week
pause_sbt(). This allows pause() to continue working during a panic()
which is not invoking KDB. This is useful when debugging graphics
drivers using the LinuxKPI.
Obtained from: kmacy @
MFC after: 1 week
It does not belong to the vmbus.
While I'm here rework the Hypercall setup, e.g. use busdma(9)
and avoid bit fields.
Discussed with: Jun Su <junsu microsoft com>
MFC after: 1 week
Sponsored by: Microsoft OSTC
Differential Revision: https://reviews.freebsd.org/D6445
The variable "size" stores number of words (4bytes). But the loop over
memory uses size as number of bytes to scan memory. As result it fetches
only 1/4th of memory.
This patch solves this problem and nvram2env fetches all NVRAM variables.
Test plan:
Pre-requisites: any MIPS board with ASCII-based NVRAM mapped into memory
* Add "device nvram2env" into kernel configuration
* Specify hints: base is mandatory (according to nvram2env(4))
hint.nvram.0.base=0x1c7f8000 (it's valid address for Asus RT-N53 with
flags = 0x4)
* Build & load kernel with bootverbose
Actual result: only part of nvram variables are found
Expected result: all variables are found
Submitted by: Michael Zhilin <mizhka@gmail.com>
Differential Revision: https://reviews.freebsd.org/D6466
This adds a BHND_BUS_GET_ATTACH_TYPE(); the primary use-case is to let
chipc make a coarse-grained determination as to whether UART, SPI, etc
drivers ought to be attached, and on fullmac devices, whether a real
CPU driver ought to be skipped for the ARM core, etc.
Tested:
* BCM4331 (BHND)
* BCM4312 (SIBA)
Submitted by: Landon Fuller <landonf@landonf.org>
Differential Revision: https://reviews.freebsd.org/D6492
This diff updates DEFINE_CLASS_2/_3 to support the specification of class
name separately from the class variable name, bringing them into sync
with their API documentation, as well as the behavior of DEFINE_CLASS_0/_1.
Nothing in the tree currently uses the _2/_3 variants, and I can't
find any references to the API outside of commits to the kobj.h
header itself; given the limitation that currently exists, I'd
be surprised if they've ever been used.
Submitted by: Landon Fuller <landonf@landonf.org>
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D6491
Replace the magic constant 127 in the loop interation count with
"PROMPTLEN - 1".
gethostname() is not guaranteed to NUL terminate the destination
string if it is too short. Decrease the length passed to gethostname()
by one, and add a NUL at the end of the buffer to make sure the
following loop to find the end of the name properly terminates.
The default: case is the likely cause of Coverity CID 1008328. If
i is 126 at the top of the loop interation where the default case
is triggered, i will be incremented to 127 by the default case,
then incremented to 128 at the top of the loop before being compared
to 127 (PROMPTLENT - 1) and terminating the loop. Then the NUL
termination code after the loop will write to ps[128]. Fix by
checking for overflow before incrementing the index and storing the
second character in the buffer.
These fixes are not guaranteed to satisfy Coverity. The code that
increments i in the 'h'/'H' and 'w'/'W' cases may be beyond its
capability to analyze, but the code appears to be safe.
Reported by: Coverity
CID: 1008328
Reviewed by: jilles, cem
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D6482
It turns out we need to leave this in place for a while so that people
running self-hosting armv6hf systems can do the builds necessary to update
to armv6 (which is now hardfloat by default).
In this configuration, a separate bootpool is not required.
This allows ZFS Boot Environments to be used with GELI encrypted ZFS pools.
Support for GPT+EFI+GELI is planned for the future.
Tested by: Joseph Mingrone, HardenedBSD
Relnotes: yes
Sponsored by: ScaleEngine Inc.
Differential Revision: https://reviews.freebsd.org/D5869