Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 1月, 2021 1 次提交
  3. 01 12月, 2020 1 次提交
  5. 04 10月, 2019 1 次提交
    • S
      of: property: Add functional dependency link from DT bindings · a3e1d1a7
      由 Saravana Kannan 提交于 
      Add device links after the devices are created (but before they are
probed) by looking at common DT bindings like clocks and
interconnects.

Automatically adding device links for functional dependencies at the
framework level provides the following benefits:

- Optimizes device probe order and avoids the useless work of
  attempting probes of devices that will not probe successfully
  (because their suppliers aren't present or haven't probed yet).

  For example, in a commonly available mobile SoC, registering just
  one consumer device's driver at an initcall level earlier than the
  supplier device's driver causes 11 failed probe attempts before the
  consumer device probes successfully. This was with a kernel with all
  the drivers statically compiled in. This problem gets a lot worse if
  all the drivers are loaded as modules without direct symbol
  dependencies.

- Supplier devices like clock providers, interconnect providers, etc
  need to keep the resources they provide active and at a particular
  state(s) during boot up even if their current set of consumers don't
  request the resource to be active. This is because the rest of the
  consumers might not have probed yet and turning off the resource
  before all the consumers have probed could lead to a hang or
  undesired user experience.

  Some frameworks (Eg: regulator) handle this today by turning off
  "unused" resources at late_initcall_sync and hoping all the devices
  have probed by then. This is not a valid assumption for systems with
  loadable modules. Other frameworks (Eg: clock) just don't handle
  this due to the lack of a clear signal for when they can turn off
  resources. This leads to downstream hacks to handle cases like this
  that can easily be solved in the upstream kernel.

  By linking devices before they are probed, we give suppliers a clear
  count of the number of dependent consumers. Once all of the
  consumers are active, the suppliers can turn off the unused
  resources without making assumptions about the number of consumers.

By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.

kbuild test robot reported clang error about missing const
Reported-by: Nkbuild test robot <lkp@intel.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20190904211126.47518-4-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a3e1d1a7
  7. 15 7月, 2019 1 次提交
  9. 28 6月, 2019 1 次提交
  11. 09 6月, 2019 1 次提交
  13. 01 5月, 2019 1 次提交
  15. 16 3月, 2018 1 次提交
    • A
      arch: remove blackfin port · 4ba66a97
      由 Arnd Bergmann 提交于 
      The Analog Devices Blackfin port was added in 2007 and was rather
active for a while, but all work on it has come to a standstill
over time, as Analog have changed their product line-up.

Aaron Wu confirmed that the architecture port is no longer relevant,
and multiple people suggested removing blackfin independently because
of some of its oddities like a non-working SMP port, and the amount of
duplication between the chip variants, which cause extra work when
doing cross-architecture changes.

Link: https://docs.blackfin.uclinux.org/Acked-by: NAaron Wu <Aaron.Wu@analog.com>
Acked-by: NBryan Wu <cooloney@gmail.com>
Cc: Steven Miao <realmz6@gmail.com>
Cc: Mike Frysinger <vapier@chromium.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      4ba66a97
  17. 18 12月, 2017 1 次提交
  19. 26 8月, 2017 1 次提交
  21. 01 5月, 2017 1 次提交
  23. 21 4月, 2017 1 次提交
  25. 14 3月, 2017 1 次提交
  27. 03 11月, 2016 1 次提交
  29. 28 10月, 2016 1 次提交
    • J
      docs: Clean up and organize the admin guide a bit · 7358bb2f
      由 Jonathan Corbet 提交于 
      The admin guide is a good start, but it's time to turn it into something
better than an unordered blob of files.  This is a first step in that
direction.  The TOC has been split up and annotated, the guides have been
reordered, and minor tweaks have been applied to a few of them.

One consequence of splitting up the TOC is that we don't really want to use
:numbered: anymore, since the count resets every time and there doesn't
seem to be a way to change that.  Eventually we probably want to group the
documents into sub-books, at which point we can go back to a single TOC,
but it's probably early to do that.
Reviewed-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      7358bb2f
  31. 24 10月, 2016 3 次提交
  33. 18 10月, 2016 1 次提交
  35. 12 10月, 2016 2 次提交
    • M
      Input: i8042 - skip selftest on ASUS laptops · 930e1924
      由 Marcos Paulo de Souza 提交于 
      On suspend/resume cycle, selftest is executed to reset i8042 controller.
But when this is done in Asus devices, subsequent calls to detect/init
functions to elantech driver fails. Skipping selftest fixes this problem.

An easier step to reproduce this problem is adding i8042.reset=1 as a
kernel parameter. On Asus laptops, it'll make the system to start with the
touchpad already stuck, since psmouse_probe forcibly calls the selftest
function.

This patch was inspired by John Hiesey's change[1], but, since this problem
affects a lot of models of Asus, let's avoid running selftests on them.

All models affected by this problem:
A455LD
K401LB
K501LB
K501LX
R409L
V502LX
X302LA
X450LCP
X450LD
X455LAB
X455LDB
X455LF
Z450LA

[1]: https://marc.info/?l=linux-input&m=144312209020616&w=2

Fixes: "ETPS/2 Elantech Touchpad dies after resume from suspend"
(https://bugzilla.kernel.org/show_bug.cgi?id=107971)
Signed-off-by: NMarcos Paulo de Souza <marcos.souza.org@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      930e1924
    • N
      lib/bitmap.c: enhance bitmap syntax · 2d13e6ca
      由 Noam Camus 提交于 
      Today there are platforms with many CPUs (up to 4K).  Trying to boot only
part of the CPUs may result in too long string.

For example lets take NPS platform that is part of arch/arc.  This
platform have SMP system with 256 cores each with 16 HW threads (SMT
machine) where HW thread appears as CPU to the kernel.  In this example
there is total of 4K CPUs.  When one tries to boot only part of the HW
threads from each core the string representing the map may be long...  For
example if for sake of performance we decided to boot only first half of
HW threads of each core the map will look like:
0-7,16-23,32-39,...,4080-4087

This patch introduce new syntax to accommodate with such use case.  I
added an optional postfix to a range of CPUs which will choose according
to given modulo the desired range of reminders i.e.:

    <cpus range>:sed_size/group_size

For example, above map can be described in new syntax like this:
0-4095:8/16

Note that this patch is backward compatible with current syntax.

[akpm@linux-foundation.org: rework documentation]
Link: http://lkml.kernel.org/r/1473579629-4283-1-git-send-email-noamca@mellanox.comSigned-off-by: NNoam Camus <noamca@mellanox.com>
Cc: David Decotigny <decot@googlers.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: David S. Miller <davem@davemloft.net>
Cc: Pan Xinhui <xinhui@linux.vnet.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d13e6ca
  37. 27 9月, 2016 2 次提交
  39. 24 9月, 2016 1 次提交
    • S
      arm64: arch_timer: Work around QorIQ Erratum A-008585 · f6dc1576
      由 Scott Wood 提交于 
      Erratum A-008585 says that the ARM generic timer counter "has the
potential to contain an erroneous value for a small number of core
clock cycles every time the timer value changes".  Accesses to TVAL
(both read and write) are also affected due to the implicit counter
read.  Accesses to CVAL are not affected.

The workaround is to reread TVAL and count registers until successive
reads return the same value.  Writes to TVAL are replaced with an
equivalent write to CVAL.

The workaround is to reread TVAL and count registers until successive reads
return the same value, and when writing TVAL to retry until counter
reads before and after the write return the same value.

The workaround is enabled if the fsl,erratum-a008585 property is found in
the timer node in the device tree.  This can be overridden with the
clocksource.arm_arch_timer.fsl-a008585 boot parameter, which allows KVM
users to enable the workaround until a mechanism is implemented to
automatically communicate this information.

This erratum can be found on LS1043A and LS2080A.
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NScott Wood <oss@buserror.net>
[will: renamed read macro to reflect that it's not usually unstable]
Signed-off-by: NWill Deacon <will.deacon@arm.com>
      f6dc1576
  41. 20 9月, 2016 1 次提交
  43. 13 9月, 2016 1 次提交
  45. 09 9月, 2016 1 次提交
    • D
      x86/pkeys: Default to a restrictive init PKRU · acd547b2
      由 Dave Hansen 提交于 
      PKRU is the register that lets you disallow writes or all access to a given
protection key.

The XSAVE hardware defines an "init state" of 0 for PKRU: its most
permissive state, allowing access/writes to everything.  Since we start off
all new processes with the init state, we start all processes off with the
most permissive possible PKRU.

This is unfortunate.  If a thread is clone()'d [1] before a program has
time to set PKRU to a restrictive value, that thread will be able to write
to all data, no matter what pkey is set on it.  This weakens any integrity
guarantees that we want pkeys to provide.

To fix this, we define a very restrictive PKRU to override the
XSAVE-provided value when we create a new FPU context.  We choose a value
that only allows access to pkey 0, which is as restrictive as we can
practically make it.

This does not cause any practical problems with applications using
protection keys because we require them to specify initial permissions for
each key when it is allocated, which override the restrictive default.

In the end, this ensures that threads which do not know how to manage their
own pkey rights can not do damage to data which is pkey-protected.

I would have thought this was a pretty contrived scenario, except that I
heard a bug report from an MPX user who was creating threads in some very
early code before main().  It may be crazy, but folks evidently _do_ it.
Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave@sr71.net>
Cc: mgorman@techsingularity.net
Cc: arnd@arndb.de
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/20160729163021.F3C25D4A@viggo.jf.intel.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      acd547b2
  47. 06 9月, 2016 1 次提交
  49. 05 9月, 2016 1 次提交
  51. 31 8月, 2016 1 次提交
  53. 26 8月, 2016 1 次提交
  55. 19 8月, 2016 1 次提交
    • B
      Update the maximum depth of C-state from 6 to 9 · 22c6bbe4
      由 baolex.ni 提交于 
      Hi Jon,

This patch is an old one, we have corrected some minor issues on the newer one.
Please only review the newest version from my last mail with this subject
"[PATCH] ACPI: Update the maximum depth of C-state from 6 to 9".
And I also attached it to this mail.

Thanks,
Baole

On 7/11/2016 6:37 AM, Jonathan Corbet wrote:
> On Mon, 4 Jul 2016 09:55:10 +0800
> "baolex.ni" <baolex.ni@intel.com> wrote:
>
>> Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
>> and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of C-state.
>> This change is reflected in one place of the kernel-param file,
>> but not in the other place where I suggest changing.
>>
>> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
>> Signed-off-by: Baole Ni <baolex.ni@intel.com>
>
> So why are there two signoffs on a single-line patch?  Which one of you
> is the actual author?
>
> Thanks,
>
> jon
>

From cf5f8aa6885874f6490b11507d3c0c86fa0a11f4 Mon Sep 17 00:00:00 2001
From: Chuansheng Liu <chuansheng.liu@intel.com>
Date: Mon, 4 Jul 2016 08:52:51 +0800
Subject: [PATCH] Update the maximum depth of C-state from 6 to 9
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently, CPUIDLE_STATE_MAX has been defined as 10 in the cpuidle head file,
and max_cstate = CPUIDLE_STATE_MAX – 1, so 9 is the right maximum depth of C-state.
This change is reflected in one place of the kernel-param file,
but not in the other place where I suggest changing.
Signed-off-by: NChuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: NBaole Ni <baolex.ni@intel.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      22c6bbe4
  57. 10 8月, 2016 1 次提交
    • M
      PCI: Update "pci=resource_alignment" documentation · 8b078c60
      由 Mathias Koehrer 提交于 
      Some uio based PCI drivers, e.g., uio_cif, do not work if the assigned PCI
memory resources are not page aligned.  By using the kernel option
"pci=resource_alignment=<align>@<bus>:<slot>.<func>" it is possible to
request page alignment for memory resources of devices.

However, this is cumbersome when using several devices, and the
bus/slot/func addresses may change if devices are added to or removed from
the system.

Extend the "pci=resource_alignment" option so we can specify the relevant
devices via PCI vendor, device, subvendor, and subdevice IDs.  The
specification of the devices via IDs is indicated by a leading string
"pci:" as argument to "pci=resource_alignment".

The format of the specification is
  pci:<vendor>:<device>[:<subvendor>:<subdevice>]

Examples:
  pci=resource_alignment=4096@pci:8086:9c22:103c:198f
  pci=resource_alignment=pci:8086:9c22       # defaults to PAGE_SIZE align

[bhelgaas: changelog, use actual vendor/device IDs in examples]
Signed-off-by: NMathias Koehrer <mathias.koehrer@etas.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8b078c60
  59. 04 8月, 2016 2 次提交
    • P
      modules: Add kernel parameter to blacklist modules · be7de5f9
      由 Prarit Bhargava 提交于 
      Blacklisting a module in linux has long been a problem.  The current
procedure is to use rd.blacklist=module_name, however, that doesn't
cover the case after the initramfs and before a boot prompt (where one
is supposed to use /etc/modprobe.d/blacklist.conf to blacklist
runtime loading). Using rd.shell to get an early prompt is hit-or-miss,
and doesn't cover all situations AFAICT.

This patch adds this functionality of permanently blacklisting a module
by its name via the kernel parameter module_blacklist=module_name.

[v2]: Rusty, use core_param() instead of __setup() which simplifies
things.

[v3]: Rusty, undo wreckage from strsep()

[v4]: Rusty, simpler version of blacklisted()
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-doc@vger.kernel.org
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      be7de5f9
    • S
      Documenation: update cgroup's document path · 09c3bcce
      由 seokhoon.yoon 提交于 
      cgroup's document path is changed to "cgroup-v1". update it.
Signed-off-by: Nseokhoon.yoon <iamyooon@gmail.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>
      09c3bcce
  61. 03 8月, 2016 1 次提交
    • B
      printk: add kernel parameter to control writes to /dev/kmsg · 750afe7b
      由 Borislav Petkov 提交于 
      Add a "printk.devkmsg" kernel command line parameter which controls how
userspace writes into /dev/kmsg.  It has three options:

 * ratelimit - ratelimit logging from userspace.
 * on  - unlimited logging from userspace
 * off - logging from userspace gets ignored

The default setting is to ratelimit the messages written to it.

This changes the kernel default setting of "on" to "ratelimit" and we do
that because we want to keep userspace spamming /dev/kmsg to sane
levels.  This is especially moot when a small kernel log buffer wraps
around and messages get lost.  So the ratelimiting setting should be a
sane setting where kernel messages should have a bit higher chance of
survival from all the spamming.

It additionally does not limit logging to /dev/kmsg while the system is
booting if we haven't disabled it on the command line.

Furthermore, we can control the logging from a lower priority sysctl
interface - kernel.printk_devkmsg.

That interface will succeed only if printk.devkmsg *hasn't* been
supplied on the command line.  If it has, then printk.devkmsg is a
one-time setting which remains for the duration of the system lifetime.
This "locking" of the setting is to prevent userspace from changing the
logging on us through sysctl(2).

This patch is based on previous patches from Linus and Steven.

[bp@suse.de: fixes]
  Link: http://lkml.kernel.org/r/20160719072344.GC25563@nazgul.tnic
Link: http://lkml.kernel.org/r/20160716061745.15795-3-bp@alien8.deSigned-off-by: NBorislav Petkov <bp@suse.de>
Cc: Dave Young <dyoung@redhat.com>
Cc: Franck Bui <fbui@suse.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      750afe7b
  63. 26 7月, 2016 1 次提交
  65. 17 7月, 2016 1 次提交
  67. 14 7月, 2016 1 次提交
  69. 10 7月, 2016 1 次提交
    • R
      PM / hibernate: Image data protection during restoration · 4c0b6c10
      由 Rafael J. Wysocki 提交于 
      Make it possible to protect all pages holding image data during
hibernate image restoration by setting them read-only (so as to
catch attempts to write to those pages after image data have been
stored in them).

This adds overhead to image restoration code (it may cause large
page mappings to be split as a result of page flags changes) and
the errors it protects against should never happen in theory, so
the feature is only active after passing hibernate=protect_image
to the command line of the restore kernel.

Also it only is built if CONFIG_DEBUG_RODATA is set.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4c0b6c10