02 Nov, 2017
1 commit
-
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
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
15 Mar, 2010
1 commit
-
Add support for bus number resources. This is for bridges with a range of
bus numbers behind them. Previously, PNP ignored bus number resources.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
05 Nov, 2009
2 commits
-
Jesse accidentally applied v1 [1] of the patchset instead of v2 [2]. This
is the diff between v1 and v2.The changes in this patch are:
- tidied vsprintf stack buffer to shrink and compute size more
accurately
- use %pR for decoding and %pr for "raw" (with type and flags) instead
of adding %pRt and %pRf[1] http://lkml.org/lkml/2009/10/6/491
[2] http://lkml.org/lkml/2009/10/13/441Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes -
This uses %pRt and %pRf to print additional resource information (type,
size, prefetchability, etc.) consistently.Signed-off-by: Bjorn Helgaas
Signed-off-by: Jesse Barnes
11 Oct, 2008
2 commits
-
pnp_dbg() is equivalent to dev_dbg() except that we can turn it
on at boot-time with the "pnp.debug" kernel parameter, so we don't
have to build a new kernel image.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown -
Use scnprintf() to build up a buffer of PNP IDs to print. This
makes the printk atomic and helps get rid of an #ifdef.Also remove an "#ifdef DEBUG" from some debug functions. The
functions only produce debug output, so it's OK to run the
function and just have the output be dropped at the end.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Signed-off-by: Len Brown
02 Aug, 2008
1 commit
-
Each resource should be printed on its own line, so start snprintf'ing
at the beginning of the buffer every time through the loop.Also, use scnprintf() rather than snprintf() when building up the
buffer to print. scnprintf() returns the number of characters actually
written into the buffer (not including the trailing NULL).snprintf() returns the number of characters that *would be* written,
assuming everything would fit in the buffer. That's nice if we want to
resize the buffer to make sure everything fits, but in this case, I
just want to keep from overflowing the buffer, and it's OK if the
output is truncated.Using snprintf() meant that my "len" could grow to be more than the
the buffer size, which makes "sizeof(buf) - len" negative, which causes
this alarming WARN_ON:
http://marc.info/?l=linux-kernel&m=121736480005656&w=2More useful snprintf/scnprintf discussion:
http://lwn.net/Articles/69419/Signed-off-by: Bjorn Helgaas
Reported-by: Pete Clements
Cc: Rene Herman
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Jul, 2008
5 commits
-
ISAPNP, PNPBIOS, and ACPI describe the "possible resource settings" of
a device, i.e., the possibilities an OS bus driver has when it assigns
I/O port, MMIO, and other resources to the device.PNP used to maintain this "possible resource setting" information in
one independent option structure and a list of dependent option
structures for each device. Each of these option structures had lists
of I/O, memory, IRQ, and DMA resources, for example:dev
independent options
ind-io0 -> ind-io1 ...
ind-mem0 -> ind-mem1 ...
...
dependent option set 0
dep0-io0 -> dep0-io1 ...
dep0-mem0 -> dep0-mem1 ...
...
dependent option set 1
dep1-io0 -> dep1-io1 ...
dep1-mem0 -> dep1-mem1 ...
...
...This data structure was designed for ISAPNP, where the OS configures
device resource settings by writing directly to configuration
registers. The OS can write the registers in arbitrary order much
like it writes PCI BARs.However, for PNPBIOS and ACPI devices, the OS uses firmware interfaces
that perform device configuration, and it is important to pass the
desired settings to those interfaces in the correct order. The OS
learns the correct order by using firmware interfaces that return the
"current resource settings" and "possible resource settings," but the
option structures above doesn't store the ordering information.This patch replaces the independent and dependent lists with a single
list of options. For example, a device might have possible resource
settings like this:dev
options
ind-io0 -> dep0-io0 -> dep1->io0 -> ind-io1 ...All the possible settings are in the same list, in the order they
come from the firmware "possible resource settings" list. Each entry
is tagged with an independent/dependent flag. Dependent entries also
have a "set number" and an optional priority value. All dependent
entries must be assigned from the same set. For example, the OS can
use all the entries from dependent set 0, or all the entries from
dependent set 1, but it cannot mix entries from set 0 with entries
from set 1.Prior to this patch PNP didn't keep track of the order of this list,
and it assigned all independent options first, then all dependent
ones. Using the example above, that resulted in a "desired
configuration" list like this:ind->io0 -> ind->io1 -> depN-io0 ...
instead of the list the firmware expects, which looks like this:
ind->io0 -> depN-io0 -> ind-io1 ...
Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
If the resource list is empty, say that explicitly. Previously,
it was confusing because often the heading was followed by zero
resource lines, then some "add resource" lines from auto-assignment,
so the "add" lines looked like current resources.Signed-off-by: Bjorn Helgaas
Signed-off-by: Andi Kleen
Acked-by: Rene Herman
Signed-off-by: Len Brown -
PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device. This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.This patch replaces the table with a linked list of resources where
the entries are allocated on demand.This removes messages like these:
pnpacpi: exceeded the max number of IO resources
00:01: too many I/O port resourcesReferences:
http://bugzilla.kernel.org/show_bug.cgi?id=9535
http://bugzilla.kernel.org/show_bug.cgi?id=9740
http://lkml.org/lkml/2007/11/30/110This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.Prior to this patch, the pnp_resource_table entries used the flags
like this:IORESOURCE_UNSET
This table entry is unused and available for use. When this flag
is set, we shouldn't look at anything else in the resource structure.
This flag is set when a resource table entry is initialized.IORESOURCE_AUTO
This resource was assigned automatically by pnp_assign_{io,mem,etc}().This flag is set when a resource table entry is initialized and
cleared whenever we discover a resource setting by reading an ISAPNP
config register, parsing a PNPBIOS resource data stream, parsing an
ACPI _CRS list, or interpreting a sysfs "set" command.Resources marked IORESOURCE_AUTO are reinitialized and marked as
IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:- before we attempt to assign resources automatically,
- if we fail to assign resources automatically,
- after disabling a deviceIORESOURCE_DISABLED
Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
Also set by PNPBIOS and PNPACPI for:- invalid IRQs or GSI registration failures
- invalid DMA channels
- I/O ports above 0x10000
- mem ranges with negative lengthAfter this patch, there is no pnp_resource_table, and the resource list
entries use the flags like this:IORESOURCE_UNSET
This flag is no longer used in PNP. Instead of keeping
IORESOURCE_UNSET entries in the resource list, we remove
entries from the list and free them.IORESOURCE_AUTO
No change in meaning: it still means the resource was assigned
automatically by pnp_assign_{port,mem,etc}(), but these functions
now set the bit explicitly.We still "clean" a device's resource list in the same places,
but rather than reinitializing IORESOURCE_AUTO entries, we
just remove them from the list.Note that IORESOURCE_AUTO entries are always at the end of the
list, so removing them doesn't reorder other list entries.
This is because non-IORESOURCE_AUTO entries are added by the
ISAPNP, PNPBIOS, or PNPACPI "get resources" methods and by the
sysfs "set" command. In each of these cases, we completely free
the resource list first.IORESOURCE_DISABLED
In addition to the cases where we used to set this flag, ISAPNP now
adds an IORESOURCE_DISABLED resource when it reads a configuration
register with a "disabled" value.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
This patch adds a "pnp_resource_type_name(struct resource *)" that
returns the string resource type. This will be used by the sysfs
"show resources" function and the debug resource dump function.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen -
In the debug resource dump, decode the flags and indicate when
a resource is disabled or has been automatically assigned.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown
Signed-off-by: Andi Kleen
15 May, 2008
1 commit
-
Add a common hex array in hexdump.c so everyone can use it.
Add a common hi/lo helper to avoid the shifting masking that is
done to get the upper and lower nibbles of a byte value.Pull the pack_hex_byte helper from kgdb as it is opencoded many
places in the tree that will be consolidated.Signed-off-by: Harvey Harrison
Acked-by: Paul Mundt
Cc: Jason Wessel
Cc: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Apr, 2008
3 commits
-
This removes more direct references to pnp_resource_table from the
pnp_assign_resources() path and the /sys user interface path.Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown -
This patch adds code to dump PNP resources before and after
assigning resources and before writing them to the device.This is enabled by CONFIG_PNP_DEBUG=y.
Signed-off-by: Bjorn Helgaas
Signed-off-by: Len Brown -
Converting the EISA ID to a string is messy and error-prone, and
we might as well use the same code for ISAPNP and PNPBIOS.PNPACPI uses the conversion done by the ACPI core with
acpi_ex_eisa_id_to_string().Signed-off-by: Bjorn Helgaas
Acked-By: Rene Herman
Signed-off-by: Len Brown
27 Jul, 2007
2 commits
-
These are manual fixups after running Lindent. No functional change.
Signed-off-by: Bjorn Helgaas
Cc: Len Brown
Cc: Adam Belay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Run Lindent on all PNP source files.
Produced by:
$ quilt new pnp-lindent
$ find drivers/pnp -name \*.[ch] | xargs quilt add
$ quilt add include/linux/{pnp.h,pnpbios.h}
$ scripts/Lindent drivers/pnp/*.c drivers/pnp/*/*.c include/linux/pnp*.h
$ quilt refresh --sortSigned-off-by: Bjorn Helgaas
Cc: Len Brown
Cc: Adam Belay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
01 Jul, 2006
1 commit
-
Signed-off-by: Jörn Engel
Signed-off-by: Adrian Bunk
08 Sep, 2005
1 commit
-
Seems pointless to require .c files to test CONFIG_PNP_DEBUG and
conditionally define DEBUG before including . Just test
CONFIG_PNP_DEBUG directly in pnp.h.Signed-off-by: Bjorn Helgaas
Cc: Adam Belay
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!
