Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.
Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.
Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de>
Link: https://lore.kernel.org/r/20200719175512.60745-1-grandmaster@al2klimov.de
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
675 mass ave cambridge ma 02139 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 441 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520071858.739733335@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This gets rid of this warning:
drivers/hwmon/hwmon-vid.c: In function 'get_via_model_d_vrm':
drivers/hwmon/hwmon-vid.c:249:27: warning: variable 'dummy' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <khali@linux-fr.org>
Since family 11h processors, AMD is exclusively using 7-bit VID codes
transmitted using a serial protocol over two pins (clock and data.)
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: David Hubbard <david.c.hubbard@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Fixed:
ERROR: code indent should use tabs where possible
ERROR: space required before the open parenthesis '('
WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable
Not fixed (url):
WARNING: line over 80 characters
Not fixed (false positive):
ERROR: Macros with complex values should be enclosed in parenthesis
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
The VRM model table was missing several Intel CPUs, resulting in wrong VRM table
entries to be used for many recent CPUs. Update it. Also, use values from
struct cpuinfo_x86 to retrieve CPU model information instead of re-calculating
it locally.
Cc: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
The VIA family 6 model D CPU (C7-D, Eden 90 nm) can use two different
VID tables, we have to check the value of a MSR to decide which one to
use.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
We had a report about a mainboard for AMD family 0Fh processors not
routing the 6th VID pin from the CPU to the hardware monitoring chip.
While the vendor should have wired the pin (or, failing that, should
have hardwired it to level high rather than low), the fact is that
none of these processors are currently known to operate at the lower
voltage levels which require the 6th VID pin. So, as a practical
workaround, I propose to ignore the 6th VID pin for these CPUs.
If this decision ever causes problems, we'll reconsider.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Frank Myhr <fmyhr@fhmtech.com>
Tested-by: Hleb Valoshka <375gnu@gmail.com>
Cc: Rudolf Marek <r.marek@assembler.cz>
Cc: Andreas Herrmann <andreas.herrmann3@amd.com>
The AMD family 10h CPUs use the same VID decoding table as the family
0Fh CPUs.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Rudolf Marek <r.marek@assembler.cz>
AMD NPT 0Fh cpus use 6 bit VID codes. Successive codes with msb 0
describe 25mV decrements, while those with msb 1 describe 12.5mV
decrements. Existing hwmon-vid.c is correct only for codes with msb 0;
add support for the codes with msb 1.
Ref:
p 309, Table 71
AMD Publication 32559, BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
Signed-off-by: Frank Myhr <fmyhr@fhmtech.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
cpu_data is currently an array defined using NR_CPUS. This means that
we overallocate since we will rarely really use maximum configured cpus.
When NR_CPU count is raised to 4096 the size of cpu_data becomes
3,145,728 bytes.
These changes were adopted from the sparc64 (and ia64) code. An
additional field was added to cpuinfo_x86 to be a non-ambiguous cpu
index. This corresponds to the index into a cpumask_t as well as the
per_cpu index. It's used in various places like show_cpuinfo().
cpu_data is defined to be the boot_cpu_data structure for the NON-SMP
case.
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>
Cc: James Bottomley <James.Bottomley@steeleye.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
If we cannot guess which VRM version the CPU uses, we set it to 0 and
log it. So we shouldn't spam the log each time vid_from_reg() is
later called with vrm 0.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Rudolf Marek <r.marek@assembler.cz>
Update the VID type for certain VIA processors and remove
the Itanium entries.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Jean Delvare <khali@linux-fr.org>