Remove duplicate lines.

Make hyperv keyboard work again.

r351049 bogusly deleted these lines from files.amd64 but failed to add them to
files.x86. Since this works on i386, add them to files.x86 rather than just
adding the

Make hyperv keyboard work again.

r351049 bogusly deleted these lines from files.amd64 but failed to add them to
files.x86. Since this works on i386, add them to files.x86 rather than just
adding them back to files.amd64.

PR: 240734
Reported by: Michael Pro

show more ...

itwd(4): driver for watchdog function in ITE Super I/O chips

The chips are commonly named with "IT" prefix.

MFC after: 19 days

Move the common x86 ipmi files to files.x86. The powerpc file list is different
enough that unification will have to wait for the next pass.

Reviewed by: jhb (verbal OK on irc)
Differential Revision

Move the common x86 ipmi files to files.x86. The powerpc file list is different
enough that unification will have to wait for the next pass.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

The x86 part of hwpmc is shared, so move it to files.x86.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

Windows ndis support is x86 only. Move the MI parts there.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

Intel's isci is part of the chipset, so it is x86 specific.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

Move hyperv to files.x86

Move the comomon part of hyperv to files.x86.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

The bxe driver, QLogic NetXtreme II Ethernet 10Gb PCIe adapter driver, is x86
specific, and only builds there. Likewise the module is built there. Move it to
the x86-only files.x86.

Reviewed by: jhb

The bxe driver, QLogic NetXtreme II Ethernet 10Gb PCIe adapter driver, is x86
specific, and only builds there. Likewise the module is built there. Move it to
the x86-only files.x86.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

The ACPI parts are identical between i386 and amd64

Apart from one MD file, ACPI is a x86 implementation, not specific to either
i386 or amd64, so put it into files.x86. Other architectures include

The ACPI parts are identical between i386 and amd64

Apart from one MD file, ACPI is a x86 implementation, not specific to either
i386 or amd64, so put it into files.x86. Other architectures include fewer
files for the same options, so it can't move into the MI files file.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

Move via padlock files to files.x86.

VIA Padlock support is for VIA C3, C7 and Eden processors, which are 64bit x86
processors.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://re

Move via padlock files to files.x86.

VIA Padlock support is for VIA C3, C7 and Eden processors, which are 64bit x86
processors.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

Apart from one MD file, aesni is common to x86. Move it into files.x86.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

Move all the hp* drivers too files.x86

The HPT drivers are all x86 only. Move them to files.x86. Because of the way we
run uudecode, we can use $M instead of needing entries for them in separate
fil

Move all the hp* drivers too files.x86

The HPT drivers are all x86 only. Move them to files.x86. Because of the way we
run uudecode, we can use $M instead of needing entries for them in separate
files.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

Move the identical x86 lines to files.x86

Move all the identical x86 lines to files.x86. The non-identical ones should be
unified and moved as well, but that would require additional changes that wo

Move the identical x86 lines to files.x86

Move all the identical x86 lines to files.x86. The non-identical ones should be
unified and moved as well, but that would require additional changes that would
need a more careful review and may not be MFCable, so I'll do them
separately. I'll delete the mildly snarky comment when things are unified.

Reviewed by: jhb (verbal OK on irc)
Differential Revision: https://reviews.freebsd.org/D21248

show more ...

Create files.x86

files.x86 is for the parts of the system that are common to both i386 and amd64
due too their nature. First up, to get the ball rolling, is fdc, the floppy disk
support. It works on

Create files.x86

files.x86 is for the parts of the system that are common to both i386 and amd64
due too their nature. First up, to get the ball rolling, is fdc, the floppy disk
support. It works only on amd64 and i386 these days, and that's unlikely to
change.

Reviewed by: jhb, cem (earlier versrions)
Differential Revision: https://reviews.freebsd.org/D21210

show more ...

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
gues

arm64: Hyper-V: enablement for ARM64 in Hyper-V (Part 3, final)

This is the last part for ARM64 Hyper-V enablement. This includes
commone files and make file changes to enable the ARM64 FreeBSD
guest on Hyper-V. With this patch, it should be able to build
the ARM64 image and install it on Hyper-V.

Reviewed by: emaste, andrew, whu
Tested by: Souradeep Chakrabarti <schakrabarti@microsoft.com>
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D36744

show more ...

Import an optimized str{n}cmp on arm64

These are from the Arm Optimized Routines and don't use the VFP so are
safe to use in the kernel.

Sponsored by: The FreeBSD Foundation

x86: remove MP_WATCHDOG

It does not work with ULE, which is the default scheduler for over a
decade.

Reviewed by: emaste, kib
Differential Revision: https://reviews.freebsd.org/D36094

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be

qat: Rename to qat_c2xxx and remove support for modern chipsets

A replacement QAT driver will be imported, but this replacement does not
support Atom C2xxx hardware. So, the existing driver will be kept
around to provide opencrypto offload support for those chipsets.

Reviewed by: pauamma, emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D35817

show more ...

isci: Disable set but unused warnings.

x86/apic: remove apic_ops

All supported Xen instances by FreeBSD provide a local APIC
implementation, so there's no need to replace the native local APIC
implementation anymore.

Leave just the ipi_

x86/apic: remove apic_ops

All supported Xen instances by FreeBSD provide a local APIC
implementation, so there's no need to replace the native local APIC
implementation anymore.

Leave just the ipi_vectored hook in order to be able to override it
with an implementation based on event channels if the underlying local
APIC is not virtualized by hardware. Note the hook cannot use ifuncs,
because at the point where ifuncs are resolved the kernel doesn't yet
know whether it will benefit from using the optimization.

Sponsored by: Citrix Systems R&D
Reviewed by: kib
Differential revision: https://reviews.freebsd.org/D33917

show more ...

pchtherm: Let the driver be compiled into the kernel

PR: 259776
MFC after: 1 week

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware

Retire synchronous PPP kernel driver sppp(4).

The last two drivers that required sppp are cp(4) and ce(4).

These devices are still produced and can be purchased
at Cronyx <http://cronyx.ru/hardware/wan.html>.

Since Roman Kurakin <rik@FreeBSD.org> has quit them, they no
longer support FreeBSD officially. Later they have dropped
support for Linux drivers to. As of mid-2020 they don't even
have a developer to maintain their Windows driver. However,
their support verbally told me that they could provide aid to
a FreeBSD developer with documentaion in case if there appears
a new customer for their devices.

These drivers have a feature to not use sppp(4) and create an
interface, but instead expose the device as netgraph(4) node.
Then, you can attach ng_ppp(4) with help of ports/net/mpd5 on
top of the node and get your synchronous PPP. Alternatively
you can attach ng_frame_relay(4) or ng_cisco(4) for HDLC.
Actually, last time I used cp(4) back in 2004, using netgraph(4)
instead of sppp(4) was already the right way to do.

Thus, remove the sppp(4) related part of the drivers and enable
by default the negraph(4) part. Further maintenance of these
drivers in the tree shouldn't be a big deal.

While doing that, remove some cruft and enable cp(4) compilation
on amd64. The ce(4) for some unknown reason marks its internal
DDK functions with __attribute__ fastcall, which most likely is
safe to remove, but without hardware I'm not going to do that, so
ce(4) remains i386-only.

Reviewed by: emaste, imp, donner
Differential Revision: https://reviews.freebsd.org/D32590
See also: https://reviews.freebsd.org/D23928

show more ...

x86: duplicate acpi_wakeup.c per i386 and amd64

The file as is is the maze of #ifdef passages, all slightly different.
Divorcing i386 and amd64 version actually makes changing the code
easier, also

x86: duplicate acpi_wakeup.c per i386 and amd64

The file as is is the maze of #ifdef passages, all slightly different.
Divorcing i386 and amd64 version actually makes changing the code
easier, also no changes for i386 are planned.

Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31931

show more ...

Microsoft Azure Network Adapter(MANA) VF support

MANA is the new network adapter from Microsoft which will be available
in Azure public cloud. It provides SRIOV NIC as virtual function to
guest OS r

Microsoft Azure Network Adapter(MANA) VF support

MANA is the new network adapter from Microsoft which will be available
in Azure public cloud. It provides SRIOV NIC as virtual function to
guest OS running on Hyper-V.

The code can be divided into two major parts. Gdma_main.c is the one to
bring up the hardware board and drives all underlying hardware queue
infrastructure. Mana_en.c contains all main ethernet driver code.
It has only tested and supported on amd64 architecture.

PR: 256336
Reviewed by: decui@microsoft.com
Tested by: whu
MFC after: 2 week
Relnotes: yes
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D31150

show more ...