The poorly named uvm.h is generally supposed to be for uvm-internal
users only.
- Narrow it to files that actually need it -- mostly files that need
to query whether curlwp is the pagedaemon, which should maybe be
exposed by an external header.
- Use uvm_extern.h where feasible and uvm_*.h for things not exposed
by it. We should split up uvm_extern.h but this will serve for now
to reduce the uvm.h dependencies.
- Use uvm_stat.h and #ifdef UVMHIST uvm.h for files that use
UVMHIST(ubchist), since ubchist is declared in uvm.h but the
reference evaporates if UVMHIST is not defined, so we reduce header
file dependencies.
- Make uvm_device.h and uvm_swap.h independently includable while
here.
ok chs@
- Don't expose how PCI bus configuration resource management is implemented.
Provide a new resource provider API:
==> pciconf_resource_init() -- Initialize a PCI configuration resources
container.
==> pciconf_resource_add() -- Add a PCI configuration resource to the
container (I/O, MEM, or prefetchable MEM). Multiple resources of
each type may be added.
==> pciconf_resource_fini() -- Tear down the PCI configurtation resources
container once the bus has been configured.
This is much easier to use than the previous method of providing an
extent map for each kind of resource, and works better for e.g. ACPI
platforms that provide potentially multiple PCI resources in tables
provided by firmware.
- Re-implement PCI configuration resource management using vmem arenas,
rather than extent maps.
This violates the security contract of the CBC construction, which
requires that the IV be unpredictable in advance; an adaptive adversary
can exploit this to verify plaintext guesses.
XXX Compile-tested only.
- Garbage-collect the obsolete GTTWSI_ALLWINNER option; it hasn't been
needed since FDT'ization of the Allwinner support code.
- Redefine thw "TWSI_*" register definitions to clearly call out:
-> The Marvell flavor of the offsets
-> The Allwinner flavor of the offsets
...and make the regular definitions indices into a register map.
- Pass the appropriate register map from the front-end to the core.
- Remove the customer register read/write callbacks -- they are no longer
needed now that each front-end passes an appropriate register map to
the core.
ifmedia_ioctl(), the hook is not required because ether_ioctl has it
(if_ethersubr.c rev. 1.160). This driver might require some additional fixes
for SIOCSIFMTU and other ioctl()s.
default case in the switch statement. Only the default case didn't check the
return value with ENETRESET. Integrate them to one ether_ioctl() with
ENETRESET test. This change might improve some other ioctl()s which return
ENETRESET by calling if_init().
ifmedia_ioctl(), the hook is not required because ether_ioctl has it
(if_ethersubr.c rev. 1.160). These drivers don't return ENETRESET in
ifmedia_ioctl(), so no functional change.
int (*mii_readreg_t)(device_t, int, int);
void (*mii_writereg_t)(device_t, int, int, int);
to:
int (*mii_readreg_t)(device_t, int, int, uint16_t *);
int (*mii_writereg_t)(device_t, int, int, uint16_t);
Now we can test if a read/write operation failed or not by the return value.
In 802.3 spec says that the PHY shall not respond to read/write transaction
to the unimplemented register(22.2.4.3). Detecting timeout can be used to
check whether a register is implemented or not (if the register conforms to
the spec). ukphy(4) can be used this for MII_MMDACR and MII_MMDAADR.
Note that I noticed that the following code do infinite loop in the
read/wirte function. If it accesses unimplemented PHY register, it will hang.
It should be fixed:
arm/at91/at91emac.c
arm/ep93xx/epe.c
arm/omap/omapl1x_emac.c
mips/ralink/ralink_eth.c
arch/powerpc/booke/dev/pq3etsec.c(read)
dev/cadence/if_cemac.c <- hkenken
dev/ic/lan9118.c
Tested with the following device:
axe+ukphy
axe+rgephy
axen+rgephy (tested by Andrius V)
wm+atphy
wm+ukphy
wm+igphy
wm+ihphy
wm+makphy
sk+makphy
sk+brgphy
sk+gentbi
msk+makphy
sip+icsphy
sip+ukphy
re+rgephy
bge+brgphy
bnx+brgphy
gsip+gphyter
rtk+rlphy
fxp+inphy (tested by Andrius V)
tlp+acphy
ex+exphy
epic+qsphy
vge+ciphy (tested by Andrius V)
vr+ukphy (tested by Andrius V)
vte+ukphy (tested by Andrius V)
Not tested (MAC):
arm:at91emac
arm:cemac
arm:epe
arm:geminigmac
arm:enet
arm:cpsw
arm:emac(omac)
arm:emac(sunxi)
arm:npe
evbppc:temac
macppc:bm
macppc:gm
mips:aumac
mips:ae
mips:cnmac
mips:reth
mips:sbmac
playstation2:smap
powerpc:tsec
powerpc:emac(ibm4xx)
sgimips:mec
sparc:be
sf
ne(ax88190, dl10019)
awge
ep
gem
hme
smsh
mtd
sm
age
alc
ale
bce
cas
et
jme
lii
nfe
pcn
ste
stge
tl
xi
aue
mue
smsc
udav
url
Not tested (PHY):
amhphy
bmtphy
dmphy
etphy
glxtphy
ikphy
iophy
lxtphy
nsphyter
pnaphy
rdcphy
sqphy
tlphy
tqphy
urlphy
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.
This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.
M_CSUM_DATA_IPv6_HL -> M_CSUM_DATA_IPv6_IPHL
M_CSUM_DATA_IPv6_HL_SET -> M_CSUM_DATA_IPv6_SET
Reduces the diff against IPv4. Also, clarify the definitions.
device and string descriptors.
Firstly: Few vendors have identical PCI-SIG vendor IDs and USB-IF vendor
IDs. As such, using the PCI vendor ID as a USB vendor ID may trample
on whomever is allocated that USB vendor ID.
Secondly: The vendor of the host controller hardware implementation has
little to nothing to do with our usbroothub implementation. Thus we
should not potentially associate any problems therewith to such third
party.
This change will result in root hubs being identified by USB Vendor ID
0x0000. Root hub vendor string will now be "NetBSD" (or, specifically:
ostype). Product ID (0x0000) and product strings remain unchanged.
kmem_alloc() with KM_SLEEP
kmem_zalloc() with KM_SLEEP
percpu_alloc()
pserialize_create()
psref_class_create()
all of these paths include an assertion that the allocation has not failed,
so callers should not assert that again.
If the CMD line is not in idle state, the interrupt handler routine will
misbehave causing an endless interrupt handler loop. This would prevent
the the kernel from getting to mountroot.
On my Pogoplug POGO-V4-A3-01, this was caused by U-Boot routing com1's TX
and RX signals to the SD card slot's CMD and DAT[0] lines respectively.
We should probably grow Marvell SoC MPP (pinmux) configuration frobs.
The benefits of the change are:
- We can reduce codes
- We can provide the same behavior between drivers
- Where/When if_ipackets is counted up
- Note that some drivers still update packet statistics in their own
way (periodical update)
- Moved bpf_mtap run in softint
- This makes it easy to MP-ify bpf
Proposed on tech-kern and tech-net
The API is used to set (or reset) a received interface of a mbuf.
They are counterpart of m_get_rcvif, which will come in another
commit, hide internal of rcvif operation, and reduce the diff of
the upcoming change.
No functional change.
- API / infrastructure changes to support memory management changes.
- Memory management improvements and bug fixes.
- HCDs should now be MP safe
- conversion to KERNHIST based debug
- FS/LS isoc support on ehci(4).
- conversion to kmem(9)
- Some USB 3 support - mostly from Takahiro HAYASHI (t-hash).
- interrupt transfers now get proper DMA operations
- general bug fixes
- kern/48308
- uhub status notification improvements
- umass(4) probe fix (applied to HEAD already)
- ohci(4) short transfer fix
queue 7 is not default, it is caused by the filter tables.
The fields are including queue number, not bitfields.
So MVXPE_DF_QUEUE_ALL (b111) means queue 7.
And also, pass all unicast addresses if it is promisc mode.
MVXPE_PXC_UPM is working in almost cases,
but this change is needed for some cases; bridging frames through inter units,
using products have consecutive MAC addresses.
This change intends to run the whole network stack in softint context
(or normal LWP), not hardware interrupt context. Note that the work is
still incomplete by this change; to that end, we also have to softint-ify
if_link_state_change (and bpf) which can still run in hardware interrupt.
This change softint-ifies at ifp->if_input that is called from
each device driver (and ieee80211_input) to ensure Layer 2 runs
in softint (e.g., ether_input and bridge_input). To this end,
we provide a framework (called percpuq) that utlizes softint(9)
and percpu ifqueues. With this patch, rxintr of most drivers just
queues received packets and schedules a softint, and the softint
dequeues packets and does rest packet processing.
To minimize changes to each driver, percpuq is allocated in struct
ifnet for now and that is initialized by default (in if_attach).
We probably have to move percpuq to softc of each driver, but it's
future work. At this point, only wm(4) has percpuq in its softc
as a reference implementation.
Additional information including performance numbers can be found
in the thread at tech-kern@ and tech-net@:
http://mail-index.netbsd.org/tech-kern/2016/01/14/msg019997.html
Acknowledgment: riastradh@ greatly helped this work.
Thank you very much!
- Add PCI Extended Configuration Space support into x86.
- Check register offset of pci_conf_read() in MD part. It returns (pcireg_t)-1
if it isn't accessible.
- Decode Extended Capability in PCI Extended Configuration Space.
Currently the following extended capabilities are decoded:
- Advanced Error Reporting
- Virtual Channel
- Device Serial Number
- Power Budgeting
- Root Complex Link Declaration
- Root Complex Event Collector Association
- Access Control Services
- Alternative Routing-ID Interpretation
- Address Translation Services
- Single Root IO Virtualization
- Page Request
- TPH Requester
- Latency Tolerance Reporting
- Secondary PCI Express
- Process Address Space ID
- LN Requester
- L1 PM Substates
The following extended capabilities are not decoded yet:
- Root Complex Internal Link Control
- Multi-Function Virtual Channel
- RCRB Header
- Vendor Unique
- Configuration Access Correction
- Multiple Root IO Virtualization
- Multicast
- Resizable BAR
- Dynamic Power Allocation
- Protocol Multiplexing
- Downstream Port Containment
- Precision Time Management
- M-PCIe
- Function Reading Status Queueing
- Readiness Time Reporting
- Designated Vendor-Specific
this driver controls CESA unit as same as mvcesa, but uses DMA engines and
does CBC operations, HMAC operations by hardware. about 2 kbytes of data
are processed at one. supported algorithms are:
- DES-CBC, 3DES-CBC, AES-CBC
- HMAC-SHA1, HMAC-MD5
non-CBC algorithm such as AES-GCM is not supported by CESA's acceleration
engine. mvcesa is still useful to implement such algorithms as combination of
accelerated block cipher and software chaining.
the buffer management(ex. fill the rx descriptors/buffers) is done by H/W in
ARMADA XP/380, and is done by S/W in ARMADA 370. the H/W BM support is not yet
implemented, so all devices use the S/W management mode at this time.
this driver supports 'counter mode', and is disabled by default.
ARMADA SoC family has new ethernet controller acceleration mode called
'enhanced mode' or 'counter mode.' it seems that backward compatibility mode
used by if_mvgbe is still working, but the specification of the old mode
is completely disappeared from SoC's reference manual.
I tested the driver using MIRABOX(ARMADA/370).
I had removed <sys/rnd.h> from files that didn't mention anything of
the rnd(9) API. But they included other files which assumed
<sys/rnd.h> had already been included.
riastradh