This patch factors out error reporting callbacks, which are currently
tightly coupled with AER.
DPC should be able to call these callbacks when DPC trigger event occurs.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 6402f7f..fd053e5 100644
--
Current DPC driver does not do recovery, e.g. calling end-point's driver's
callbacks, which sanitize the sw.
DPC driver implements link_reset callback, and calls pci_do_recovery.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 2d976a6..6
Implement error_resume callback in DPC, which, after DPC trigger event
enumerates the devices beneath.
Signed-off-by: Oza Pawandeep
diff --git a/drivers/pci/pcie/pcie-dpc.c b/drivers/pci/pcie/pcie-dpc.c
index 68296ec..4c6bef3 100644
--- a/drivers/pci/pcie/pcie-dpc.c
+++ b/drivers/pci/pcie/pcie-d
This patch set brings in error handling support for DPC
The current implementation of AER and error message broadcasting to the
EP driver is tightly coupled and limited to AER service driver.
It is important to factor out broadcasting and other link handling
callbacks. So that not only when AER ge
On Sun, Jan 07, 2018 at 02:23:09PM +0100, Michal Hocko wrote:
> On Sun 07-01-18 13:44:02, Mike Galbraith wrote:
> > On Sun, 2018-01-07 at 11:18 +0100, Michal Hocko wrote:
> > > On Sun 07-01-18 10:11:15, Greg KH wrote:
> > > > On Sun, Jan 07, 2018 at 06:14:22AM +0100, Mike Galbraith wrote:
> > > > >
On Sun, Jan 07, 2018 at 10:06:59AM -0500, Pavel Tatashin wrote:
> Hi Greg,
>
> I reverted suse12 back to:
> 13dae54cb229d078635f159dd8afe16ae683980b
> x86/kaiser: Move feature detection up (bsc#1068032).
>
> And, still do not see the problem. So, whatever fixes the issue comes
> before kaiser.
O
On 12/15/2017 01:18 PM, Hannes Reinecke wrote:
> On 12/08/2017 10:42 AM, Jason Yan wrote:
>> If the PHY burst too many events, we will alloc a lot of events for the
>> worker. This may leads to memory exhaustion.
>>
>> Dan Williams suggested to shut down the PHY if the events reached the
>> thresho
On Sun, Jan 07, 2018 at 09:23:47PM -0500, David Miller wrote:
> From: Thomas Gleixner
> Date: Sun, 7 Jan 2018 21:56:39 +0100 (CET)
>
> > I surely agree, but we have gone the way of PTI without the ability of
> > exempting individual processes exactly for one reason:
> >
> > Lack of time
> >
>
On Sun, 2018-01-07 at 08:12 -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 05 Jan 2018 20:41:41 +0100
> Knut Omang escreveu:
>
> > On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote:
> > > Em Thu, 04 Jan 2018 21:15:31 +0100
> > > Knut Omang escreveu:
> > >
> > > > > I'm surprised t
These two patches are general improvement for meson pinctrl driver.
It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
one hardware block even its pin groups live inside two differet hardware
domains,
which for example EE vs AO domain here.
This idea is motivated by Ma
On Mon, 8 Jan 2018, Dominik Brodowski wrote:
> On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> > As the meltdown/spectre problem affects several CPU architectures, it makes
> > sense to have common way to express whether a system is affected by a
> > particular vulnerability or n
We introduce a macro FUNCTION_EX here, the main motivation is
trying to have the possibility to expand the macro with the same of the
'.name' number but different multiple '.groups/.num_groups' numbers.
With this change, the meson pinctrl drivr is capable of have one uniform
'function' name but wi
The 'uart_ao_b_groups' for the UART_AO_B pins is already defined which is
living inside the AO domain, for these pins which are routed out from EE domain,
we need to correct them with the 'FUNCTION_EX' macro, otherwise there is
a conflict in the code level.
Also slightly adjust the name to make it
On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation s
>> @@ -708,11 +708,11 @@ static void svc_addr(struct seq_file *seq, struct
>> sockaddr_atmsvc *addr)
>> static int e164[] = { 1, 8, 4, 6, 1, 0 };
>>
>> if (*addr->sas_addr.pub) {
>> - seq_printf(seq, "%s", addr->sas_addr.pub);
>> + seq_puts(seq, addr->sa
On Fri, Jan 05, 2018 at 01:12:33PM +, Will Deacon wrote:
> For non-KASLR kernels where the KPTI behaviour has not been overridden
> on the command line we can use ID_AA64PFR0_EL1.CSV3 to determine whether
> or not we should unmap the kernel whilst running at EL0.
>
> Reviewed-by: Suzuki K Poul
On 07/01/2018 19:44, Alexandre Belloni wrote:
> On 07/01/2018 at 19:07:13 +0100, Daniel Lezcano wrote:
>> On 05/01/2018 15:30, Alexandre Belloni wrote:
>>> With the new TCB clocksource driver, atmel platforms are now able to boot
>>> without the PIT driver. Allow unselecting it.
>>>
>>> Signed-off-
Linus,
On Sun, 7 Jan 2018, Linus Torvalds wrote:
> The one thing I want to do now that Meltdown and Spectre are public,
> is to give a *big* shout-out to the x86 people, and Thomas Gleixner in
> particular for really being on top of this. It's been one huge
> annoyance, and honestly, Thomas real
Use PSCI based mitigation for speculative execution attacks targeting
the branch predictor. The approach is similar to the one used for
Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
test if the firmware supports the capability.
If the secure firmware has been updated with the
Add the older Broadcom ID as well as the new Cavium ID for ThunderX2
CPUs.
Signed-off-by: Jayachandran C
---
arch/arm64/include/asm/cputype.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 84385b9..cce5735 100644
-
On Sun, Jan 07, 2018 at 10:48:01PM +0100, Thomas Gleixner wrote:
> Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and
> spectre_v2.
>
> Signed-off-by: Thomas Gleixner
> ---
> arch/x86/Kconfig |1 +
> arch/x86/kernel/cpu/bugs.c | 29
On 06/01/18 22:39, Nick Desaulniers wrote:
> Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
> frowned upon by others.
>
> https://lkml.org/lkml/2013/9/23/500
>
> Here, the VLAIS was used because the size of the bitmap returned from
> xen_mc_entry() depended on possibly (
On Sun, Jan 07, 2018 at 10:48:00PM +0100, Thomas Gleixner wrote:
> As the meltdown/spectre problem affects several CPU architectures, it makes
> sense to have common way to express whether a system is affected by a
> particular vulnerability or not. If affected the way to express the
> mitigation s
The labels and branching order of the error path of 'aspeed_adc_probe()'
are broken.
Re-order the labels and goto statements.
Signed-off-by: Christophe JAILLET
---
Not sure where it comes from.
Merge conflict incorrectly fixed?
---
drivers/iio/adc/aspeed_adc.c | 7 ---
1 file changed, 4 inse
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, January 5, 2018 11:43 PM
> To: linux-kernel@vger.kernel.org; k...@vger.kernel.org
> Cc: Kang, Luwei
> Subject: [PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit mo
HI Martin:
On 01/08/18 14:07, Yixun Lan wrote:
> Hi Martin
>
> On 01/08/18 04:19, Martin Blumenstingl wrote:
>> Hi Yixun,
>>
>> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote:
>>> Describe the pinctrl info for the UART controller which is found
>>> in the Meson-AXG SoCs.
>>>
>>> Signed-off-by:
On Sun, Jan 07, 2018 at 09:35:39PM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> With pipe-user-pages-hard set to 'N', users were actually only allowed
> up to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
>
> Fix this to allow up to 'N' buffers, as would be expected.
Interestin
On 6 January 2018 at 03:18, Mark Brown wrote:
> On Fri, Jan 05, 2018 at 12:53:28PM -0600, Rob Herring wrote:
>> On Thu, Jan 04, 2018 at 03:22:44PM +0800, Chunyan Zhang wrote:
>
>> > + - regulator-suspend-microvolt: the default voltage which regulator
>> > + would be set in suspend. The volta
On Mon, Jan 08, 2018 at 12:01:04PM +0530, Ravi Bangoria wrote:
>
>
> On 01/08/2018 10:49 AM, Srikar Dronamraju wrote:
> > * Ravi Bangoria [2018-01-06 11:12:46]:
> >
> >> Recently, how the pointers being printed with %p has been changed
> >> by commit ad67b74d2469 ("printk: hash addresses printed
From: Marco Franchi Sent: Friday, January 05, 2018 11:03 PM
>Hi,
>
>I am getting the following warning on a imx6ul-evk board running linux-next
>20180105:
>
>[9.233290] [ cut here ]
>[9.242068] WARNING: CPU: 0 PID: 0 at
>./include/linux/netfilter.h:233 arp_rcv+0x1f8
On Fri, Jan 05, 2018 at 01:12:41PM +, Will Deacon wrote:
> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
> and can theoretically be attacked by malicious code.
>
> This patch implements a PSCI-based mitigation for these CPUs when available.
> The call into firmware
On 01/08/2018 10:49 AM, Srikar Dronamraju wrote:
> * Ravi Bangoria [2018-01-06 11:12:46]:
>
>> Recently, how the pointers being printed with %p has been changed
>> by commit ad67b74d2469 ("printk: hash addresses printed with %p").
>> This is causing a regression while showing offset in the
>> up
On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote:
> On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote:
>
> > On Sat, Dec 30, 2017 at 12:31 AM, James Morris
> > wrote:
> > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
> > >
> > >> Hello James,
> > >>
> > >> Seems
Currently, migrating tasks to cpu0 unconditionally happens when the
heap is empty, since cp->elements[].cpu was initialized to 0(=cpu0).
We have to distinguish between the empty case and cpu0 to avoid the
unnecessary migrations. Therefore, it has to return an invalid value
e.i. -1 in that case.
Si
It would be better to try to check other siblings first if
SD_PREFER_SIBLING is flaged when pushing tasks - migration.
Suggested-by: Peter Zijlstra
Signed-off-by: Byungchul Park
Reviewed-by: Steven Rostedt (VMware)
---
kernel/sched/rt.c | 80
Change from v10
-. modify a comment a bit as Steven suggested
Change from v9
-. modify a comment a bit so to be more clear as Juri suggested
Change from v8
-. add suggested-by Peterz
-. add several comments
Change from v7
-. fix a trivial typo
-. modify commit messages to expla
It would be better to try to check other siblings first if
SD_PREFER_SIBLING is flaged when pushing tasks - migration.
Suggested-by: Peter Zijlstra
Signed-off-by: Byungchul Park
Acked-by: Juri Lelli
---
kernel/sched/deadline.c | 82 -
1 file chan
Changes from v2
- Run spellchecker over the text and fix typos
- Add acked-by Daniel
Changes from v1
- Enhance commit msg
- Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1
-8<-
>From 7735382d07ae6a61d740ae39ba2ecf169d43b8a2 Mon Sep 17 00:00:00 2001
From: Byungch
Hi Martin
On 01/08/18 04:19, Martin Blumenstingl wrote:
> Hi Yixun,
>
> On Sat, Jan 6, 2018 at 1:10 AM, Yixun Lan wrote:
>> Describe the pinctrl info for the UART controller which is found
>> in the Meson-AXG SoCs.
>>
>> Signed-off-by: Yixun Lan
>> ---
>> arch/arm64/boot/dts/amlogic/meson-axg.
The RTC range validation code can be factored into rtc_valid_range()
function to avoid duplicate code.
Signed-off-by: Baolin Wang
---
drivers/rtc/interface.c | 30 ++
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/rtc/interface.c b/drivers/r
>From our investigation for all RTC drivers, 1 driver will be expired before
year 2017, 7 drivers will be expired before year 2038, 23 drivers will be
expired before year 2069, 72 drivers will be expired before 2100 and 104
drivers will be expired before 2106. Especially for these early expired
dri
We need use rtc->range_max to valid if the time values are valid,
and the time values are saved by time64_t type. So change the
rtc->range_max to time64_t type for comparison correctly.
Signed-off-by: Baolin Wang
---
include/linux/rtc.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
Hi Alexandre,
On 25 December 2017 at 19:10, Baolin Wang wrote:
> If we convert one large time values to rtc_time, in the original formula
> 'days * 86400' can be overflowed in 'unsigned int' type to make the formula
> get one incorrect remain seconds value. Thus we can use div_s64_rem()
> functio
Fixes the following coding style issue as noted by checkpatch.pl
at multiple lines:
Comparison to NULL could be written "!token"
Signed-off-by: Sumit Pundir
---
drivers/staging/greybus/camera.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/
From: Eric Biggers
Before validating the given value against pipe_min_size,
do_proc_dopipe_max_size_conv() calls round_pipe_size(), which rounds the
value up to pipe_min_size. Therefore, the second check against
pipe_min_size is redundant. Remove it.
Signed-off-by: Eric Biggers
---
fs/pipe.c
From: Eric Biggers
round_pipe_size() calculates the number of pages the requested size
corresponds to, then rounds the page count up to the next power of 2.
However, it also rounds everything < PAGE_SIZE up to PAGE_SIZE.
Therefore, there's no need to actually translate the size into a page
count
From: Eric Biggers
A pipe's size is represented as an 'unsigned int'. As expected, writing
a value greater than UINT_MAX to /proc/sys/fs/pipe-max-size fails with
EINVAL. However, the F_SETPIPE_SZ fcntl silently truncates such values
to 32 bits, rather than failing with EINVAL as expected. (It
From: Eric Biggers
pipe-user-pages-hard and pipe-user-pages-soft are only supposed to apply
to unprivileged users, as documented in both Documentation/sysctl/fs.txt
and the pipe(7) man page.
However, the capabilities are actually only checked when increasing a
pipe's size using F_SETPIPE_SZ, not
From: Eric Biggers
With pipe-user-pages-hard set to 'N', users were actually only allowed
up to 'N - 1' buffers; and likewise for pipe-user-pages-soft.
Fix this to allow up to 'N' buffers, as would be expected.
Signed-off-by: Eric Biggers
---
fs/pipe.c | 4 ++--
1 file changed, 2 insertions(+
From: Eric Biggers
The pipe buffer limits are accessed without any locking, and may be
changed at any time by the sysctl handlers. In theory this could cause
problems for expressions like the following:
pipe_user_pages_hard && user_bufs > pipe_user_pages_hard
... since the assembly code mi
From: Eric Biggers
pipe_proc_fn() is no longer needed, as it only calls through to
proc_dopipe_max_size(). Just put proc_dopipe_max_size() in the
ctl_table entry directly, and remove the unneeded EXPORT_SYMBOL() and
the ENOSYS stub for it.
(The reason the ENOSYS stub isn't needed is that the pi
This series simplifies the sysctl handler for pipe-max-size and fixes
another set of bugs related to the pipe buffer limits:
- The root user wasn't allowed to exceed the limits when creating new
pipes.
- There was an off-by-one error when checking the limits, so a limit of
N was actually trea
On Saturday 06 January 2018 07:12 AM, David Lechner wrote:
> On 01/05/2018 04:42 AM, Sekhar Nori wrote:
>> On Friday 05 January 2018 08:29 AM, David Lechner wrote:
>>> On 01/04/2018 11:50 AM, David Lechner wrote:
On 1/4/18 6:39 AM, Sekhar Nori wrote:
>>
> This is a pretty huge patch again
On 2/01/2018 17:10, Linus Walleij wrote:
On Thu, Dec 28, 2017 at 4:19 PM, Dmitry Mastykin wrote:
When using mcp23s08 module with gpio-keys, often (50% of boots)
it fails to get irq numbers with message:
"gpio-keys keys: Unable to get irq number for GPIO 0, error -6".
Seems that irqs must be se
On Sun, Jan 07, 2018 at 10:50:58PM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> > Thomas Gleixner wrote:
> > > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > > meltdown, spectre_v1 and spectre_v2.
> >
> > It is ca
* Ravi Bangoria [2018-01-06 11:12:46]:
> Recently, how the pointers being printed with %p has been changed
> by commit ad67b74d2469 ("printk: hash addresses printed with %p").
> This is causing a regression while showing offset in the
> uprobe_events file. Instead of %p, use %px to display offse
Hi all,
Changes since 20180105:
The akpm-current tree still had its build failure for which I applied a patch.
Non-merge commits (relative to Linus' tree): 7364
7774 files changed, 310809 insertions(+), 212731 deletions(-)
---
ftrace_module_init happen after dynamic_debug_setup, it is desired that
cleanup should be called after this label however in current implementation
it is called in free module label,ie:even though ftrace in not initialized,
from so many fail case ftrace_release_mod() will be called and unnecessary
On Sat, Jan 06, 2018 at 01:30:59AM +0100, Borislav Petkov wrote:
> On Fri, Jan 05, 2018 at 11:08:06AM -0600, Josh Poimboeuf wrote:
> > I seem to recall that we also discussed the need for this for converting
> > pvops to use alternatives, though the "why" is eluding me at the moment.
>
> Ok, here'
Hello everyone,
this series adds initial support for the NVIDIA Tegra194 "Xavier"
system-on-chip. Initially UART, I2C, SDMMC, as well as the PMIC
are supported, allowing booting to a console.
The changes consist almost completely of the new device trees,
however some fixes are required in the BPM
The Tegra194 power management controller has one additional register
aperture to be specified in the device tree node.
Signed-off-by: Mikko Perttunen
---
Documentation/devicetree/bindings/arm/tegra/nvidia,tegra186-pmc.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devic
The Tegra194 PMC is mostly compatible with Tegra186, including in all
currently supported features. As such, add a new compatibility string
but point to the existing Tegra186 SoC data for now.
Signed-off-by: Mikko Perttunen
---
drivers/soc/tegra/pmc.c | 1 +
1 file changed, 1 insertion(+)
diff
Add device tree files for the Tegra194 P2972- development board.
The board consists of the P2888 compute module and the P2822 baseboard.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/Makefile| 1 +
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 246 +++
Add the configuration option to enable support for the Tegra194
system-on-chip, and enable it by default in the arm64 defconfig.
Signed-off-by: Mikko Perttunen
---
arch/arm64/configs/defconfig | 1 +
drivers/soc/tegra/Kconfig| 10 ++
2 files changed, 11 insertions(+)
diff --git a/a
The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
and they are not placed contiguously in memory. The current channel
management in the BPMP driver does not support this.
Simplify and refactor the channel management such that only one atomic
transmit channel and one receive ch
Add the chip-level device tree, including binding headers, for the
NVIDIA Tegra194 "Xavier" system-on-chip. Only a small subset of devices
are initially available, enough to boot to UART console.
Signed-off-by: Mikko Perttunen
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 334
On 01/06/18 09:24, Vincent Legoll wrote:
> No need to get into the submenu to disable all related
> config entries.
>
> This makes it easier to disable all RUNTIME_TESTS config options
> without entering the submenu. It will also enable one to see that
> en/dis-abled state from the outside menu.
>
Hi,
On 1/5/2018 4:31 PM, Kishon Vijay Abraham I wrote:
>> +enum phy_mode phy_get_mode(struct phy *phy)
>> +{
>> +enum phy_mode ret;
>> +
>> +if (!phy || !phy->ops->get_mode)
>> +return PHY_MODE_INVALID;
>> +
>> +mutex_lock(&phy->mutex);
>> +ret = phy->ops->get_mode(phy)
On Thu, Jan 04, 2018 at 04:35:51PM -0600, Pierre-Louis Bossart wrote:
> Pierre-Louis Bossart (8):
> ASoC: acpi: add missing includes for non-ACPI platforms
> ASoC: Intel: Fix Kconfig with top-level selector
> ASoC: Intel: Kconfig: Simplify-clarify ACPI/PCI dependencies
> ASoC: Intel: docum
On 05-01-18, 14:19, Stephen Boyd wrote:
> On 12/29, Viresh Kumar wrote:
> Could you please point to Kevin's comments and also include the
https://lkml.kernel.org/r/m2r30i4w35@baylibre.com
> reasoning behind magic values in the commit text for the patch?
> It would be very helpful to know why
On Sun, Jan 07, 2018 at 09:50:31AM +0100, Michal Hocko wrote:
> On Sat 06-01-18 17:07:33, Guenter Roeck wrote:
> > The following build error is seen when building metag:meta2_defconfig
> > or metag:tz1090_defconfig.
> >
> > arch/metag/kernel/process.c: In function '__metag_elf_map':
> > arch/metag
On 08/01/18 11:35, Chris Packham wrote:
> Hi Miquel, Ezequiel,
>
> On 23/12/17 05:56, Ezequiel Garcia wrote:
>> On 22 December 2017 at 12:53, Miquel RAYNAL
>> wrote:
>>> Hello Chris,
>>>
>>> On Fri, 22 Dec 2017 12:19:04 +1300
>>> Chris Packham wrote:
>>>
From: Kalyan Kinthada
The
Commit 'mm/vmalloc.c: replace opencoded 4-level page walkers' in -next is
supposed to fix a sparc64 crash (or at least that is how I interpret the
commit log). Unfortunately, it actually causes sparc64 images to crash
reliably, at least in my qemu tests.
...
[1.922450] Calibrating delay using
On 05-01-18, 23:18, Rafael J. Wysocki wrote:
> On Fri, Jan 5, 2018 at 9:37 PM, Leonard Crestez
> wrote:
> > Hello,
> >
> > When using the schedutil governor together with the softlockup detector
> > all CPUs go to their maximum frequency on a regular basis. This seems
> > to be because the watchd
On 2018年01月06日 00:21, Willem de Bruijn wrote:
On Fri, Jan 5, 2018 at 4:54 AM, Jason Wang wrote:
This patch allows userspace to attach eBPF filter to tun. This will
allow to implement VM dataplane filtering in a more efficient way
compared to cBPF filter by allowing either qemu or libvirt to
a
On Mon, Jan 08, 2018 at 01:22:04AM +0300, Alexey Dobriyan wrote:
> Thomas Gleixner wrote:
> > Create /sys/devices/system/cpu/vulnerabilities folder and files for
> > meltdown, spectre_v1 and spectre_v2.
>
> It is called "grep -e '^bugs' /proc/cpuinfo".
>
> kpti is deduceable from .config and /pro
On 08-01-18, 10:04, Anson Huang wrote:
> Add 696MHz operating point for i.MX6UL, only for those
> parts with speed grading fuse set to 2b'10 supports
> 696MHz operating point, so, speed grading check is also
> added for i.MX6UL in this patch, the clock tree for each
> operating point are as below:
When PSHOLD in a Qualcomm platform is deasserted the PMIC will perform
either a power off or a restart of the system. The action to take is
configured in the PON block, which is controlled by a separate driver.
As the configuration logic was added to the pm8941-pwrkey driver the
comment in do_msm_
These macros are no longer used, so they can
be removed.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/include/lustre_lib.h | 249
1 file changed, 249 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_lib.h
b/drivers/staging/lustre/lustre
This l_wait_event_exclusive_head() will wait indefinitely
if the timeout is zero. If it does wait with a timeout
and times out, the timeout for next time is set to zero.
The can be mapped to a call to either
wait_event_idle_exclusive()
or
wait_event_idle_exclusive_timeout()
depending in the tim
replace l_wait_event() with wait_event_idle_timeout() and explicit
loop. This approach is easier to understand.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ptlrpc/client.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lustre/
This use of l_wait_event() is a polling loop that re-checks
every second. Make this more obvious with a while loop
and wait_event_idle_timeout().
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ptlrpc/niobuf.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
d
When 'back_to_sleep()' is passed as the 'timeout' function,
the effect is to wait indefinitely for the event, polling
once after the timeout.
If LWI_ON_SIGNAL_NOOP is given, then after the timeout
we allow fatal signals to interrupt the wait.
Make this more obvious in both places "back_to_sleep()"
Rather an using l_wait_event(), use wait_event_idle_timeout()
with an explicit loop so it is easier to see what is happening.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ptlrpc/service.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/
We can replace l_wait_event() with
wait_event_idle_timeout() here providing we call the
timeout function when wait_event_idle_timeout() returns zero.
As ptlrpc_expired_set() returns 1, the l_wait_event() aborts of the
first timeout.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ptl
Replace l_wait_event with wait_event_idle_timeout() and call the
handler function explicitly. This makes it more clear
what is happening.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/ptlrpc/sec.c | 34
1 file changed, 24 insertions(+), 10 deletions(-
This is the last remaining use of l_wait_event().
It is the only use of LWI_TIMEOUT_INTR_ALL() which
has a meaning that timeouts can be interrupted.
Only interrupts by "fatal" signals are allowed, so
introduce l_wait_event_abortable_timeout() to
support this.
Signed-off-by: NeilBrown
---
drivers
This waiter currently wakes up every second to re-test if
imp_flight is zero. If we ensure wakeup is called whenever
imp_flight is decremented to zero, we can just have a simple
wait_event_idle_timeout().
So add a wake_up_all to the one place it is missing, and simplify
the wait_event.
Signed-of
If a signal-callback (lwi_on_signal) is set without lwi_allow_intr, as
is the case in ldlm_completion_ast(), the behavior depends on the
timeout set.
If a timeout is set, then signals are ignored. If the timeout is
reached, the timeout handler is called. If the timeout handler
return 0, which ld
Two places that LWI_TIMEOUT_INTERVAL() is used, the outcome is a
simple polling loop that polls every second for some event (with a
limit).
So write a simple loop to make this more apparent.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/llite/llite_lib.c | 11 +--
drivers
If l_wait_event() is given a function to be called on a signal,
but no timeout or timeout handler, then the intr function is simply
called at the end if the wait was aborted by a signal.
So a simpler way to write the code (in the one place this case is
used) it to open-code the body of the function
The new TASK_IDLE state (TASK_UNINTERRUPTIBLE | __TASK_NOLOAD)
is not much used. One way to make it easier to use is to
add wait_event*() family functions that make use of it.
This patch adds:
wait_event_idle()
wait_event_idle_timeout()
wait_event_idle_exclusive()
wait_event_idle_exclusive
When the lwi arg has a timeout, but no timeout
callback function, l_wait_event() acts much the same as
wait_event_idle_timeout() - the wait is not interruptible and
simply waits for the event or the timeouts.
The most noticable difference is that the return value is
-ETIMEDOUT or 0, rather than 0
cfs_time_seconds() converts a number of seconds to the
matching number of jiffies.
The standard way to do this in Linux is "* HZ".
So discard cfs_time_seconds() and use "* HZ" instead.
Signed-off-by: NeilBrown
---
.../lustre/include/linux/libcfs/libcfs_debug.h |4 ++--
.../lustre/includ
When the lwi arg is full of zeros, l_wait_event() behaves almost
identically to the standard wait_event_idle() interface, so use that
instead.
l_wait_event() uses TASK_INTERRUPTIBLE, but blocks all signals.
wait_event_idle() uses the new TASK_IDLE and so avoids adding
to the load average without n
lustre sometimes wants to wait for an event, but abort if
one of a specific list of signals arrives. This is a little
bit like wait_event_killable(), except that the signals are
identified a different way.
So introduce l_wait_event_abortable() which provides this
functionality.
Having separate fu
This flag is never set, so remove checks and remove
the flag.
Signed-off-by: NeilBrown
---
drivers/staging/lustre/lustre/include/lustre_net.h |6 --
drivers/staging/lustre/lustre/ptlrpc/sec_gc.c |4 +---
2 files changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/stagi
Hi,
this is a revised version of the patch series I sent under a similar
subject in mid December.
Improvements are:
- new wait_event_idle* macros are now in include/linux/wait.h which
Ack from peterz.
- *all* waits are now TASK_IDLE or TASK_INTERRUPTIBLE and so don't
affect the l
FYI, we noticed the following commit (built with gcc-7):
commit: 5aad04554302fc1fbb5924d0f8f68946ec5c06f7 ("kernfs, sysfs, cgroup,
intel_rdt: Support fs_context")
https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context
in testcase: trinity
with following parameters:
Hi Olsa,
What about this fix now? Thanks!
On Tue, Dec 26, 2017 at 05:26:56PM +0800, changbin...@intel.com wrote:
> From: Changbin Du
>
> The terminal character '\0' should take into account as size of the string
> buffer. Without this fix, the '--graph-funcs', '--nograph-funcs' and
> '--trace-fu
1 - 100 of 443 matches
Mail list logo
