Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 30 3月, 2020 1 次提交
  3. 20 8月, 2019 1 次提交
  5. 14 6月, 2019 1 次提交
  7. 31 5月, 2019 1 次提交
    • T
      treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 157 · c942fddf
      由 Thomas Gleixner 提交于 
      Based on 3 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

  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 [author] [kishon] [vijay] [abraham]
  [i] [kishon]@[ti] [com] 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

  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 [author] [graeme] [gregory]
  [gg]@[slimlogic] [co] [uk] [author] [kishon] [vijay] [abraham] [i]
  [kishon]@[ti] [com] [based] [on] [twl6030]_[usb] [c] [author] [hema]
  [hk] [hemahk]@[ti] [com] 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

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 1105 file(s).
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NAllison Randal <allison@lohutok.net>
Reviewed-by: NRichard Fontana <rfontana@redhat.com>
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.202006027@linutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c942fddf
  9. 09 4月, 2019 1 次提交
  11. 05 4月, 2019 2 次提交
  13. 27 3月, 2019 1 次提交
  15. 14 1月, 2019 1 次提交
  17. 21 12月, 2018 1 次提交
  19. 14 12月, 2018 1 次提交
  21. 31 10月, 2018 1 次提交
  23. 18 5月, 2018 1 次提交
  25. 12 5月, 2018 1 次提交
  27. 23 2月, 2018 1 次提交
  29. 07 2月, 2018 1 次提交
  31. 20 7月, 2017 1 次提交
  33. 19 4月, 2017 1 次提交
  35. 28 1月, 2017 1 次提交
    • I
      x86/boot/e820: Create coherent API function names for E820 range operations · ab6bc04c
      由 Ingo Molnar 提交于 
      We have these three related functions:

 extern void e820_add_region(u64 start, u64 size, int type);
 extern u64  e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
 extern u64  e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);

But it's not clear from the naming that they are 3 operations based around the
same 'memory range' concept. Rename them to better signal this, and move
the prototypes next to each other:

 extern void e820__range_add   (u64 start, u64 size, int type);
 extern u64  e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
 extern u64  e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);

Note that this improved organization of the functions shows another problem that was easy
to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
will be fixed in a separate patch.

No change in functionality.

Cc: Alex Thorlton <athorlton@sgi.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Huang, Ying <ying.huang@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Jackson <pj@sgi.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ab6bc04c
  37. 21 12月, 2016 1 次提交
    • L
      ACPI / osl: Remove acpi_get_table_with_size()/early_acpi_os_unmap_memory() users · 6b11d1d6
      由 Lv Zheng 提交于 
      This patch removes the users of the deprectated APIs:
 acpi_get_table_with_size()
 early_acpi_os_unmap_memory()
The following APIs should be used instead of:
 acpi_get_table()
 acpi_put_table()

The deprecated APIs are invented to be a replacement of acpi_get_table()
during the early stage so that the early mapped pointer will not be stored
in ACPICA core and thus the late stage acpi_get_table() won't return a
wrong pointer. The mapping size is returned just because it is required by
early_acpi_os_unmap_memory() to unmap the pointer during early stage.

But as the mapping size equals to the acpi_table_header.length
(see acpi_tb_init_table_descriptor() and acpi_tb_validate_table()), when
such a convenient result is returned, driver code will start to use it
instead of accessing acpi_table_header to obtain the length.

Thus this patch cleans up the drivers by replacing returned table size with
acpi_table_header.length, and should be a no-op.
Reported-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6b11d1d6
  39. 17 9月, 2016 1 次提交
  41. 31 8月, 2016 3 次提交
    • A
      ACPI / tables: do not report the number of entries ignored by acpi_parse_entries() · 99b0efd7
      由 Al Stone 提交于 
      The function acpi_parse_entries_array() has a limiting parameter,
max_entries, which tells the function to stop looking at subtables
once that limit has been reached.  If the limit is reached, it is
reported.  However, the logic is incorrect in that the loop to
examine all subtables will always report that zero subtables have
been ignored since it does not continue once the max_entries have
been reached.

One approach to fixing this would be to correct the logic so that
all subtables are examined, even if we have hit the max_entries, but
without executing all the callback functions.  This could be risky
since we cannot guarantee that no callback will ever have side effects
that another callback depends on to work correctly.

So, the simplest approach is to just remove the part of the error
message that will always be incorrect.
Signed-off-by: NAl Stone <ahs3@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      99b0efd7
    • A
      ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtables · 8726d4f4
      由 Al Stone 提交于 
      The acpi_parse_entries_array() function currently returns the very first
time there is any error found by one of the callback functions, or if one
of the callbacks returns a non-zero value.  However, the ACPI subtables
being traversed could still have valid entries that could be used by one
of the callback functions.  And, if the comments are correct, that is
what should happen -- always traverse all of the subtables, calling as
many of the callbacks as possible.

This patch makes the function consistent with its description so that it
will properly invoke all callbacks for all matching entries, for all
subtables, instead of stopping abruptly as it does today.

This does change the semantics of using acpi_parse_entries_array().  In
examining all users of the function, none of them rely on the current
behavior; that is, there appears to be no assumption that either all
subtables are traversed and all callbacks invoked, or that the function
will return immediately on any error from a callback.  Each callback
operates independently.  Hence, there should be no functional change
due to this change in semantics.

Future patches being prepared will rely on this new behavior; indeed,
they were written assuming the acpi_parse_entries_array() function
operated as its comments describe.  For example, a callback that
counts the number of subtables of a specific type can now be assured
that as many subtables as possible have been enumerated.
Signed-off-by: NAl Stone <ahs3@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8726d4f4
    • A
      ACPI / tables: fix incorrect counts returned by acpi_parse_entries_array() · fa162a05
      由 Al Stone 提交于 
      The static function acpi_parse_entries_array() is provided an array of
type struct acpi_subtable_proc that has a callback function and a count.
The count should reflect how many times the callback has been called.
However, the current code only increments the 0th element of the array,
regardless of the number of entries in the array, or which callback has
been invoked.  The result is that we know the total number of callbacks
made but we cannot determine which callbacks were made, nor how often.
The fix is to index into the array of structs and increment the proper
counts.

There is one place in the x86 code for acpi_parse_madt_lapic_entries()
where the counts for each callback are used.  If no LAPICs *and* no
X2APICs are found, an ENODEV is supposed to be returned; as it stands,
the count of X2APICs will always be zero, regardless of what is in the
MADT.  Should there be no LAPICs, ENODEV will be returned in error, if
there are X2APICs in the MADT.

Otherwise, there are no other functional consequences of the count being
done as it currently is; all other uses simply check that the return value
from acpi_parse_entries_array() or passed back via its callers is either
non-zero, an error, or in one case just ignored.

In future patches, I will also need these counts to be correct; I need
to count the number of instances of subtables of certain types within
the MADT to determine whether or not an ACPI IORT is required or not,
and report when it is not present when it should be.
Signed-off-by: NAl Stone <ahs3@redhat.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fa162a05
  43. 22 6月, 2016 3 次提交
  45. 06 5月, 2016 1 次提交
  47. 19 4月, 2016 2 次提交
    • L
      ACPI / tables: Convert initrd table override to table upgrade mechanism · 5d881327
      由 Lv Zheng 提交于 
      This patch converts the initrd table override mechanism to the table
upgrade mechanism by restricting its usage to the tables released with
compatibility and more recent revision.

This use case has been encouraged by the ACPI specification:

 1. OEMID:
    An OEM-supplied string that identifies the OEM.

 2. OEM Table ID:
    An OEM-supplied string that the OEM uses to identify the particular data
    table. This field is particularly useful when defining a definition
    block to distinguish definition block functions. OEM assigns each
    dissimilar table a new OEM Table Id.

 3. OEM Revision:
    An OEM-supplied revision number. Larger numbers are assumed to be newer
    revisions.

For OEMs, good practices will ensure consistency when assigning OEMID and
OEM Table ID fields in any table. The intent of these fields is to allow
for a binary control system that support services can use. Because many
support function can be automated, it is useful when a tool can
programatically determine which table release is a compatible and more
recent revision of a prior table on the same OEMID and OEM Table ID.

The facility can now be used by the vendors to upgrade wrong tables for bug
fixing purpose, thus lockdep disabling taint is not suitable for it and it
should be a default 'y' option to implement the spec encouraged use case.

Note that, by implementing table upgrade inside of ACPICA itself, it is
possible to remove acpi_table_initrd_override() and tables can be upgraded
by acpi_install_table() automatically. Though current ACPICA impelentation
hasn't implemented this, this patched changes the table flag setting timing
to allow this to be implemented in ACPICA without changing the code here.

Documentation of initrd override mechanism is upgraded accordingly.
Original-by: NOctavian Purdila <octavian.purdila@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5d881327
    • L
      ACPI / tables: Move table override mechanisms to tables.c · 5ae74f2c
      由 Lv Zheng 提交于 
      This patch moves acpi_os_table_override() and
acpi_os_physical_table_override() to tables.c.

Along with the mechanisms, acpi_initrd_initialize_tables() is also moved to
tables.c to form a static function. The following functions are renamed
according to this change:
 1. acpi_initrd_override() -> renamed to early_acpi_table_init(), which
    invokes acpi_table_initrd_init()
 2. acpi_os_physical_table_override() -> which invokes
    acpi_table_initrd_override()
 3. acpi_initialize_initrd_tables() -> renamed to acpi_table_initrd_scan()
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ae74f2c
  49. 10 3月, 2016 2 次提交
  51. 15 10月, 2015 2 次提交
  53. 08 7月, 2015 1 次提交
  55. 25 3月, 2015 2 次提交
  57. 27 11月, 2014 2 次提交
  59. 17 6月, 2014 1 次提交