arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS

arch: Remove Itanium (IA-64) architecture

The Itanium architecture is obsolete, and an informal survey [0] reveals
that any residual use of Itanium hardware in production is mostly HP-UX
or OpenVMS based. The use of Linux on Itanium appears to be limited to
enthusiasts that occasionally boot a fresh Linux kernel to see whether
things are still working as intended, and perhaps to churn out some
distro packages that are rarely used in practice.

None of the original companies behind Itanium still produce or support
any hardware or software for the architecture, and it is listed as
'Orphaned' in the MAINTAINERS file, as apparently, none of the engineers
that contributed on behalf of those companies (nor anyone else, for that
matter) have been willing to support or maintain the architecture
upstream or even be responsible for applying the odd fix. The Intel
firmware team removed all IA-64 support from the Tianocore/EDK2
reference implementation of EFI in 2018. (Itanium is the original
architecture for which EFI was developed, and the way Linux supports it
deviates significantly from other architectures.) Some distros, such as
Debian and Gentoo, still maintain [unofficial] ia64 ports, but many have
dropped support years ago.

While the argument is being made [1] that there is a 'for the common
good' angle to being able to build and run existing projects such as the
Grid Community Toolkit [2] on Itanium for interoperability testing, the
fact remains that none of those projects are known to be deployed on
Linux/ia64, and very few people actually have access to such a system in
the first place. Even if there were ways imaginable in which Linux/ia64
could be put to good use today, what matters is whether anyone is
actually doing that, and this does not appear to be the case.

There are no emulators widely available, and so boot testing Itanium is
generally infeasible for ordinary contributors. GCC still supports IA-64
but its compile farm [3] no longer has any IA-64 machines. GLIBC would
like to get rid of IA-64 [4] too because it would permit some overdue
code cleanups. In summary, the benefits to the ecosystem of having IA-64
be part of it are mostly theoretical, whereas the maintenance overhead
of keeping it supported is real.

So let's rip off the band aid, and remove the IA-64 arch code entirely.
This follows the timeline proposed by the Debian/ia64 maintainer [5],
which removes support in a controlled manner, leaving IA-64 in a known
good state in the most recent LTS release. Other projects will follow
once the kernel support is removed.

[0] https://lore.kernel.org/all/CAMj1kXFCMh_578jniKpUtx_j8ByHnt=s7S+yQ+vGbKt9ud7+kQ@mail.gmail.com/
[1] https://lore.kernel.org/all/[email protected]/
[2] https://gridcf.org/gct-docs/latest/index.html
[3] https://cfarm.tetaneutral.net/machines/list/
[4] https://lore.kernel.org/all/[email protected]/
[5] https://lore.kernel.org/all/ff58a3e76e5102c94bb5946d99187b358def688a.camel@physik.fu-berlin.de/

Acked-by: Tony Luck <[email protected]>
Signed-off-by: Ard Biesheuvel <[email protected]>

show more ...

parisc: parisc-agp requires SBA IOMMU driver

Add a dependency to the SBA IOMMU driver to avoid:
ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined!

Reported-by: kernel test robot

parisc: parisc-agp requires SBA IOMMU driver

Add a dependency to the SBA IOMMU driver to avoid:
ERROR: modpost: "sba_list" [drivers/char/agp/parisc-agp.ko] undefined!

Reported-by: kernel test robot <[email protected]>
Cc: [email protected]
Signed-off-by: Helge Deller <[email protected]>

show more ...

treewide: replace '---help---' in Kconfig files with 'help'

Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasi

treewide: replace '---help---' in Kconfig files with 'help'

Since commit 84af7a6194e4 ("checkpatch: kconfig: prefer 'help' over
'---help---'"), the number of '---help---' has been gradually
decreasing, but there are still more than 2400 instances.

This commit finishes the conversion. While I touched the lines,
I also fixed the indentation.

There are a variety of indentation styles found.

a) 4 spaces + '---help---'
b) 7 spaces + '---help---'
c) 8 spaces + '---help---'
d) 1 space + 1 tab + '---help---'
e) 1 tab + '---help---' (correct indentation)
f) 1 tab + 1 space + '---help---'
g) 1 tab + 2 spaces + '---help---'

In order to convert all of them to 1 tab + 'help', I ran the
following commend:

$ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

char: Fix Kconfig indentation

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig

Signed-off-by: Krzysztof Ko

char: Fix Kconfig indentation

Adjust indentation from spaces to tab (+optional two spaces) as in
coding style with command like:
$ sed -e 's/^ /\t/' -i */Kconfig

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

ia64: remove support for machvecs

The only thing remaining of the machvecs is a few checks if we are
running on an SGI UV system. Replace those with the existing
is_uv_system() check that has been

ia64: remove support for machvecs

The only thing remaining of the machvecs is a few checks if we are
running on an SGI UV system. Replace those with the existing
is_uv_system() check that has been rewritten to simply check the
OEM ID directly.

That leaves us with a generic kernel that is as fast as the previous
DIG/ZX1/UV kernels, but can support all hardware. Support for UV
and the HP SBA IOMMU is now optional based on new config options.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Tony Luck <[email protected]>

show more ...

ia64: remove the zx1 swiotlb machvec

The aim of this machvec is to support devices with < 32-bit dma
masks. But given that ia64 only has a ZONE_DMA32 and not a ZONE_DMA
that isn't supported by swio

ia64: remove the zx1 swiotlb machvec

The aim of this machvec is to support devices with < 32-bit dma
masks. But given that ia64 only has a ZONE_DMA32 and not a ZONE_DMA
that isn't supported by swiotlb either.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Tony Luck <[email protected]>

show more ...

char/agp: remove the sgi-agp driver

The SGI SN2 support is about to be removed. Remove this driver that
depends on the SN2 support.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml

char/agp: remove the sgi-agp driver

The SGI SN2 support is about to be removed. Remove this driver that
depends on the SN2 support.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Tony Luck <[email protected]>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

drm/i915: Make AGP support optional

We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So mak

drm/i915: Make AGP support optional

We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So make AGP support optional. As before, we will
fail the i915 init for UMS and gen3 KMS the same as before if
intel_agp isn't around.

intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going
to save that for a later cleaning.

At least my gen2 still works with the patch and CONFIG_AGP=n.

v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI

Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>

show more ...

Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"

This reverts commit f191f144079b0083c6fa7d01a4acbd7263fb5032.

The AMD 751 and 761 chipsets are used on the UP1000, UP1100, and UP1500
OE

Revert "agp: AMD AGP is used on UP1100 & UP1500 alpha boxen"

This reverts commit f191f144079b0083c6fa7d01a4acbd7263fb5032.

The AMD 751 and 761 chipsets are used on the UP1000, UP1100, and UP1500
OEM motherboards, but they neglect to do anything to make AGP work.

According to Ivan Kokshaysky:
There is quite fundamental conflict between the Alpha architecture and
x86 AGP implementation - Alpha is entirely cache coherent by design,
while x86 AGP is not (I mean native AGP DMA transactions, not a PCI over
AGP). There are no such things as non-cacheable mappings or software
support for cache flushing/invalidation on Alpha, so x86 AGP code won't
work on Nautilus.

So there's no point in allowing this driver to be configured on Alpha.

Signed-off-by: Matt Turner <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>

show more ...

Update broken web addresses in the kernel.

The patch below updates broken web addresses in the kernel

Signed-off-by: Justin P. Mattock <[email protected]>
Cc: Maciej W. Rozycki <macro@linux-m

Update broken web addresses in the kernel.

The patch below updates broken web addresses in the kernel

Signed-off-by: Justin P. Mattock <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Finn Thain <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Matt Turner <[email protected]>
Cc: Dimitry Torokhov <[email protected]>
Cc: Mike Frysinger <[email protected]>
Acked-by: Ben Pfaff <[email protected]>
Acked-by: Hans J. Koch <[email protected]>
Reviewed-by: Finn Thain <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>

show more ...

x86, k8: Rename k8.[ch] to amd_nb.[ch] and CONFIG_K8_NB to CONFIG_AMD_NB

The file names are somehow misleading as the code is not specific to
AMD K8 CPUs anymore. The files accomodate code for other

x86, k8: Rename k8.[ch] to amd_nb.[ch] and CONFIG_K8_NB to CONFIG_AMD_NB

The file names are somehow misleading as the code is not specific to
AMD K8 CPUs anymore. The files accomodate code for other AMD CPU
northbridges as well.

Same is true for the config option which is valid for AMD CPU
northbridges in general and not specific to K8.

Signed-off-by: Andreas Herrmann <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: H. Peter Anvin <[email protected]>

show more ...

x86, k8 nb: Fix boot crash: enable k8_northbridges unconditionally on AMD systems

de957628ce7c84764ff41331111036b3ae5bad0f changed setting of the
x86_init.iommu.iommu_init function ptr only when GAR

x86, k8 nb: Fix boot crash: enable k8_northbridges unconditionally on AMD systems

de957628ce7c84764ff41331111036b3ae5bad0f changed setting of the
x86_init.iommu.iommu_init function ptr only when GART IOMMU is
found.

One side effect of it is that num_k8_northbridges
is not initialized anymore if not explicitly
called. This resulted in uninitialized pointers in
<arch/x86/kernel/cpu/intel_cacheinfo.c:amd_calc_l3_indices()>,
for example, which uses the num_k8_northbridges thing through
node_to_k8_nb_misc().

Fix that through an initcall that runs right after the PCI
subsystem and does all the scanning. Then, remove initialization
in gart_iommu_init() which is a rootfs_initcall and we're
running before that.

What is more, since num_k8_northbridges is being used in other
places beside GART IOMMU, include it whenever we add AMD CPU
support. The previous dependency chain in kconfig contained

K8_NB depends on AGP_AMD64|GART_IOMMU

which was clearly incorrect. The more natural way in terms of
hardware dependency should be

AGP_AMD64|GART_IOMMU depends on K8_NB depends on CPU_SUP_AMD &&
PCI. Make it so Number One!

Signed-off-by: Borislav Petkov <[email protected]>
Cc: FUJITA Tomonori <[email protected]>
Cc: Joerg Roedel <[email protected]>
LKML-Reference: <20100312144303.GA29262@aftab>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Joerg Roedel <[email protected]>

show more ...

agp/amd64: Remove GART dependency on AGP_AMD64

The GART IOMMU code has no strong dependency to the AMD64
AGP code. So the automatic selection of AGP_AMD64 for GART
can be removed.

Cc: Dave Jones <d

agp/amd64: Remove GART dependency on AGP_AMD64

The GART IOMMU code has no strong dependency to the AMD64
AGP code. So the automatic selection of AGP_AMD64 for GART
can be removed.

Cc: Dave Jones <[email protected]>
Signed-off-by: Pavel Vasilyev <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

x86 gart: rename CONFIG_IOMMU to CONFIG_GART_IOMMU

This patch renames the IOMMU config option to GART_IOMMU because in fact it
means the GART and not general support for an IOMMU on x86.

Signed-off

x86 gart: rename CONFIG_IOMMU to CONFIG_GART_IOMMU

This patch renames the IOMMU config option to GART_IOMMU because in fact it
means the GART and not general support for an IOMMU on x86.

Signed-off-by: Joerg Roedel <[email protected]>
Acked-by: Muli Ben-Yehuda <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>

show more ...

video gfx: merge kconfig menus

Move AGP and DRM menus into the video graphics support menu.
They use 'menuconfig' so that they can all be disabled with
one selection.
Make the console menu use '

video gfx: merge kconfig menus

Move AGP and DRM menus into the video graphics support menu.
They use 'menuconfig' so that they can all be disabled with
one selection.
Make the console menu use 'menuconfig' so that it can all be
disabled with one selection.
Make the frame buffer menu use 'menuconfig' so that it can all be
disabled with one selection.

Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Signed-off-by: Antonino Daplas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

agp: AMD AGP is used on UP1100 & UP1500 alpha boxen

Signed-off-by: Dave Airlie <[email protected]>

[AGPGART] VIA and SiS AGP chipsets are x86-only

There's no point in troubling the Alpha, IA-64, PowerPC and PARISC
people with SiS and VIA options. Andrew thinks it helps find bugs,
but there's no

[AGPGART] VIA and SiS AGP chipsets are x86-only

There's no point in troubling the Alpha, IA-64, PowerPC and PARISC
people with SiS and VIA options. Andrew thinks it helps find bugs,
but there's no evidence of that.

Signed-off-by: Matthew Wilcox <[email protected]>
Signed-off-by: Dave Jones <[email protected]>

show more ...

[PARISC] Add support for Quicksilver AGPGART

Signed-off-by: Kyle McMartin <[email protected]>

[AGPGART] Make AGP depend on PCI

Fixes possible compile error in amd64 with pci=n
pointed out by Adrian Bunk.

Signed-off-by: Dave Jones <[email protected]>

[PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded.

- Rename the GART_IOMMU option to IOMMU to make clear it's not
just for AMD
- Rewrite the help text to better emphatise t

[PATCH] x86_64: Rename IOMMU option, fix help and mark option embedded.

- Rename the GART_IOMMU option to IOMMU to make clear it's not
just for AMD
- Rewrite the help text to better emphatise this fact
- Make it an embedded option because too many people get it wrong.

To my astonishment I discovered the aacraid driver tests this
symbol directly. This looks quite broken to me - it's an internal
implementation detail of the PCI DMA API. Can the maintainer
please clarify what this test was intended to do?

Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

[PATCH] x86_64: use select for GART_IOMMU to enable AGP

The AGP default doesn't work well with other selects, so use a select for
GART_IOMMU as well. Remove a redundant default for SWIOTLB as well.

[PATCH] x86_64: use select for GART_IOMMU to enable AGP

The AGP default doesn't work well with other selects, so use a select for
GART_IOMMU as well. Remove a redundant default for SWIOTLB as well.

Signed-off-by: Roman Zippel <[email protected]>
Signed-off-by: Andi Kleen <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Dave Jones <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: Jeff Garzik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

[AGPGART] Enable SIS AGP driver on x86-64 for EM64T systems

Enable SIS AGP driver on x86-64 for EM64T systems

Untested so far

Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Dave Jones <dave

[AGPGART] Enable SIS AGP driver on x86-64 for EM64T systems

Enable SIS AGP driver on x86-64 for EM64T systems

Untested so far

Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Dave Jones <[email protected]>

show more ...

[AGPGART] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets

Untested so far
[davej: but needed for some newer EM64T systems]

Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Dave Jon

[AGPGART] x86_64: Enable VIA AGP driver on x86-64 for VIA P4 chipsets

Untested so far
[davej: but needed for some newer EM64T systems]

Signed-off-by: Andi Kleen <[email protected]>
Signed-off-by: Dave Jones <[email protected]>

show more ...

[AGPGART] Lots of CodingStyle/whitespace cleanups.

Eliminate trailing whitespace.
s/if(/if (/
s/for(/for (/

Signed-off-by: Dave Jones <[email protected]>