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
Override global retry limit (which is set in R92C_RL) via per-frame
TX descriptor field. Obsoletes D3840 (should work better with 2+ vaps).
Tested with RTL8188EU and RTL8192CUS in STA mode (maxretry = [3-9]).
- Revert the change for seed(0) in r300384. I misunderstood the standard
and while our random() implementation in libkern may be improved, it
handles the seed(0) case fine.
Pointed out by: bde, ache
After r285994, sysctl(8) was fixed to use 273.15 instead of 273.20 as 0C
reference and as result, the temperature read in sysctl(8) now exibits a
+0.1C difference.
This commit fix the kernel references to match the reference value used in
sysctl(8) after r285994.
Sponsored by: Rubicon Communications (Netgate)
The GPIO hardware should not be owned by a single device, this defeats any
chance of use of the GPIO controller as an interrupt source.
ow(4) is now the only consumer of this 'feature' before we can remove it
for good.
Discussed with: ian, bsdimp
- Revert r300377: The implementation claims to return a value
within the range. [1]
- Adjust the value for the case of a zero seed, whihc according
to standards should be equivalent to a seed of value 1.
Pointed out by: cem
wpa_supplicant(8) expects to see 'scan complete' event after every
scan command; in case, when event is not sent it will hang for
indefinite time.
PR: 209198
the current offset (spelled: "fs.pindex") until it is known whether a
backing object exists. In fact, if not for the fact that the backing
object offset is zero when there is no backing object, this update would
produce a broken offset.
Reviewed by: kib
This is a long standing problem: our random() function returns an
unsigned integer but the rand provided by ndis(4) returns an int.
Scale it down.
MFC after: 2 weeks
In ndis(4) we expose a rand() function that was constantly reseeding
with a time depending function every time it was called. This
essentially broke the reasoning behind seeding, and rendered srand()
a no-op.
Keep it simple, just use random() and srandom() as it's meant to work.
It would have been tempting to just go for arc4random() but we
want to mimic Microsoft, and we don't need crypto-grade randomness
here.
PR: 209616
MFC after: 2 weeks
compilers can emit arm instructions that require 8-byte alignment. The
alignment-sensitive instructions were added in armv5, which has to be
supported by our combined v4/v5 kernels, so the value is set uncoditionally
for all arm architecture versions.
Also adjust the comment to explain in more detail why the macros have the
form and values they do.
Per advice from bde@, maintain the unsignedness of the value of _ALIGNBYTES
(but do so using his second choice of allowing sizeof() to supply the
unsignedness, rather than just hardcoding '8U', which in my mind would
require an even more verbose comment to explain why it's right). Also
explain in the comment that the resulting type of _ALIGN() is equivelent
to uinptr_t on arm (32-bit unsigned int), but it's purposely spelled as
"unsigned" to avoid problems with including other header files. Even
including machine/_types.h to allow use of __uintptr_t causes compilation
failures because of this header being included (indirectly) in asm code.
The discussion that led to this change (albeit at a glacial pace) is at
https://lists.freebsd.org/pipermail/svn-src-head/2014-November/064593.html
