Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 01:59:35PM +, Alan Cox wrote: > > which means that POC is relying 64-bit address speculation. > > In the places coverity found the user supplied value is 32-bit, > > People have 32bit computers as well as 64bit and in some cases 32bit is > fine for an attack depending

Re: [PATCH v4 00/14] Modernization and fixes for NuBus subsystem

On Sun, 7 Jan 2018, Geert Uytterhoeven wrote: > it does complain when using spaces only ("please, no spaces at the > _start_ of a line"). > Checkpatch accepts this tab: int map(struct mm_id * mm_idp, unsigned long virt, unsigned long len, int prot, int phys_fd, unsigned long long

Re: [PATCH v2 net-next] net: tracepoint: exposing sk_faimily in tracepoint inet_sock_set_state

> On Jan 6, 2018, at 10:31 PM, Yafang Shao wrote: > > As of now, there're two sk_family are traced with sock:inet_sock_set_state, > which are AF_INET and AF_INET6. > So the sk_family are exposed as well. > Then we can conveniently use it to do the filter. > > Both

[patch 0/2] sysfs/cpu: Implement generic vulnerabilites directory

The meltdown/spectre vulnerabilities affect several architectures and people are asking for a common way to figure out whether a system is affected or not. Create /sys/devices/system/cpu/vulnerabilites and the files /sys/devices/system/cpu/vulnerabilites/meltdown

[patch 1/2] sysfs/cpu: Add vulnerability folder

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 should be common as well. Create /sys/devices/system/cpu/vulnerabilities

[patch 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions

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 + 2 files changed, 30 insertions(+) ---

[patch V2 0/2] sysfs/cpu: Implement generic vulnerabilites directory

The meltdown/spectre vulnerabilities affect several architectures and people are asking for a common way to figure out whether a system is affected or not. Create /sys/devices/system/cpu/vulnerabilites and the files /sys/devices/system/cpu/vulnerabilites/meltdown

[patch V2 1/2] sysfs/cpu: Add vulnerability folder

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 should be common as well. Create /sys/devices/system/cpu/vulnerabilities

[patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions

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 + 2 files changed, 30 insertions(+) ---

Re: [PATCH] Revert "ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells"

Stefan Wahren writes: > This reverts commit 014d6da6cb2525d7f48fb08c705cb130cc7b5f4a. > > The DT clean up could trigger an endless deferred probe of DWC2 USB driver > on the Raspberry Pi 2/3. So revert the change until we fixed the probing > issue. Why's that? I found

Linux 3.2.98

I'm announcing the release of the 3.2.98 kernel. All users of the 3.2 kernel series should upgrade. The updated 3.2.y git tree can be found at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-3.2.y and can be browsed at the normal kernel.org git web

Re: "BUG: using smp_processor_id() in preemptible" with KPTI on 4.14.11

On Sun, Jan 07, 2018 at 09:53:19AM +0100, Thomas Zeitlhofer wrote: > On Sun, Jan 07, 2018 at 09:17:18AM +0100, Greg Kroah-Hartman wrote: > > On Sat, Jan 06, 2018 at 10:38:38PM +0100, Thomas Zeitlhofer wrote: [...] > > > While solving the previous problem, this patch also introduces new > > > "fun

Re: [PATCH] USB: musb: da8xx: remove clock con_id

On 01/05/2018 07:50 PM, David Lechner wrote: There is only one clock for the DA8xx MUSB device, so we don't need the con_id, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner ---

Re: [PATCH] USB: ohci: da8xx: remove clk con_id

On 01/05/2018 07:53 PM, David Lechner wrote: The ohci-da8xx device only has one clock, so a con_id is not needed, so remove it. This way we don't have to add an unnecessary property to the device tree bindings for the clock. Signed-off-by: David Lechner --- superseded

Re: [PATCH] mm: ratelimit end_swap_bio_write() error

On (01/06/18 14:34), Michal Hocko wrote: > > zsmalloc allocation is just one possibility; an error in > > compressing algorithm is another one, yet is rather unlikely. > > most likely it's OOM which can cause problems. but in any case > > it's sort of unclear what should be done. an error can be a

[PATCH v5 30/44] ARM: da8xx: add new sata_refclk init using common clock frmework

This adds the new SATA REFCLK clock init in mach-davinci/devices-da8xx.c using the new common clock framework drivers. The #ifdefs are needed to prevent compile errors until the entire ARCH_DAVINCI is converted. Also, the #includes are sorted since we are adding some here. Signed-off-by: David

[PATCH v5 37/44] ARM: dm365: Remove legacy clock init

This removes the unused legacy clock init code from arch/arm/mach-davinci/dm365.c. Signed-off-by: David Lechner --- arch/arm/mach-davinci/dm365.c | 449 +- 1 file changed, 1 insertion(+), 448 deletions(-) diff --git

[PATCH v5 44/44] ARM: dts: da850: Add clocks

This adds clock provider nodes for da850 and wires them up to all of the devices. Signed-off-by: David Lechner --- arch/arm/boot/dts/da850.dtsi | 167 +++ 1 file changed, 167 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi

[PATCH v5 36/44] ARM: dm355: Remove legacy clock init

This removes the unused legacy clock init code from arch/arm/mach-davinci/dm355.c. Signed-off-by: David Lechner --- arch/arm/mach-davinci/dm355.c | 357 +- 1 file changed, 1 insertion(+), 356 deletions(-) diff --git

[PATCH v5 33/44] ARM: davinci: switch to common clock framework

This switches ARCH_DAVINCI to use the common clock framework. The legacy clock code in arch/arm/mach-davinci/ is no longer used. New drivers in drivers/clk/davinci/ are used instead. A few macros had to be moved to prevent compile errors. Signed-off-by: David Lechner ---

[PATCH v5 31/44] ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS

The common clock framework will take care of disabling unused clocks when we switch from the legacy davinci clocks and having this enabled will cause compile errors after we switch, so remove it now. Signed-off-by: David Lechner --- arch/arm/mach-davinci/Kconfig

Re: Avoid speculative indirect calls in kernel

On Sun, Jan 07, 2018 at 07:55:11PM +0100, Borislav Petkov wrote: > > Just like you have to trust your plane's pilot eventhough you don't > > know him personally. > > Funny you should make that analogy. Remember that germanwings pilot? > People trusted him too. > > Now imagine if the plane had

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

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

Cache-controlling kernel APIs for user-space programs to defeat Meltdown/Spectre and to make more secure applications portably

I've been thinking that the problem that makes Meltdown/Spectre possible is a synchronization problem between the use of the cache by all running processes and invalidating the cache when switching tasks so that the contents of the cache for a process don't exist when switching and running to

[PATCH -next] ASoC: mediatek: mt2701: fix return value check in mt2701_afe_pcm_dev_probe()

In case of error, the function syscon_node_to_regmap() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: dfa3cbb83e09 ("ASoC: mediatek: modify MT2701 AFE driver to adapt mfd device") Signed-off-by: Wei Yongjun

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

On Sun, Jan 07, 2018 at 11:08:24AM +0100, Thomas Gleixner wrote: > On Sat, 6 Jan 2018, Alexei Starovoitov wrote: > > which clearly states that bpf_tail_call() was used in the attack. > > Yet none of the intel nor arm patches address speculation in > > this bpf helper! > > It means that: > > - gpz

Re: [PATCH 00/13] replace print_symbol() with printk()-s

On (01/05/18 15:42), Petr Mladek wrote: > > I am all for it. But I would postpone this removal to 4.17. > The reason is rather ugly. 13th patch is already in arc tree. > We would need to shuffle the patch or coordinate pull requests. JFI, the patch is in Linus's tree as of now

[PATCH v2] pinctrl: qcom: Add msm8998 pinctrl driver

From: "Khan, Imran" Add initial pinctrl driver to support pin configuration with pinctrl framework for msm8998. Signed-off-by: Imran Khan Acked-by: Rob Herring [bjorn: Consolidated function groups] Signed-off-by: Bjorn Andersson

[PATCH v5 04/44] clk: davinci: Add platform information for TI DA850 PLL

This adds platform-specific declarations for the PLL clocks on TI DA850/ OMAP-L138/AM18XX SoCs. Signed-off-by: David Lechner --- drivers/clk/davinci/Makefile| 1 + drivers/clk/davinci/pll-da850.c | 67 +

[PATCH v5 02/44] clk: davinci: New driver for davinci PLL clocks

This adds a new driver for mach-davinci PLL clocks. This is porting the code from arch/arm/mach-davinci/clock.c to the common clock framework. Additionally, it adds device tree support for these clocks. The ifeq ($(CONFIG_COMMON_CLK), y) in the Makefile is needed to prevent compile errors until

[PATCH v5 03/44] clk: davinci: Add platform information for TI DA830 PLL

This adds platform-specific declarations for the PLL clocks on TI DA830/ OMAP-L137/AM17XX SoCs. Signed-off-by: David Lechner --- drivers/clk/davinci/Makefile| 1 + drivers/clk/davinci/pll-da830.c | 38 ++ include/linux/clk/davinci.h

[PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks

This adds a new binding for the PLL IP blocks in the mach-davinci family of processors. Currently, only the SYSCLKn and AUXCLK outputs are needed, but in the future additional child nodes could be added for OBSCLK and BPDIV. Note: Although these PLL controllers are very similar to the TI Keystone

[PATCH v5 08/44] clk: davinci: Add platform information for TI DM646x PLL

This adds platform-specific declarations for the PLL clocks on TI DaVinci 646x based systems. Signed-off-by: David Lechner --- drivers/clk/davinci/Makefile | 1 + drivers/clk/davinci/pll-dm646x.c | 44

[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 5aad045543: kernel_BUG_at_fs/super.c

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:

Re: [PATCH net-next V2 2/2] tun: allow to attach ebpf socket filter

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

sparc64 crashes in -next due to 'mm/vmalloc.c: replace opencoded 4-level page walkers'

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

Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants

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

Re: [PATCH v3 00/10] ASoC: Intel: Kconfig+acpi fixes

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:

[PATCH 6/6] arm64: tegra: Add device tree for the Tegra194 P2972-0000 board

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 +

[PATCH 3/6] soc/tegra: pmc: Add Tegra194 compatibility string

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

[PATCH 4/6] dt-bindings: tegra: Add documentation for nvidia,tegra194-pmc

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

[PATCH 0/6] Initial support for NVIDIA Tegra194

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

[PATCH 2/6] soc/tegra: Add Tegra194 SoC configuration option

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

[PATCH 1/6] firmware: tegra: Simplify channel management

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

linux-next: Tree for Jan 8

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(-)

Re: [PATCH] trace_uprobe: Display correct offset in uprobe_events

* 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.

Re: [v2, 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

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

RE: WARNING: CPU: 0 PID: 0 at ./include/linux/netfilter.h:233 arp_rcv

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

Re: [PATCH 4/7] pipe: fix off-by-one error when checking buffer limits

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

Re: [PATCH v2 3/6] clocksource/drivers: atmel-pit: allow unselecting ATMEL_PIT

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. >>> >>>

[PATCH 2/2] pinctrl: meson-axg: correct the pin expansion of UART_AO_B

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

[PATCH 1/2] pinctrl: meson: introduce a macro to have name/groups seperated

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

Re: [PATCH 4.14 023/159] mm/sparsemem: Allocate mem_section at runtime for CONFIG_SPARSEMEM_EXTREME=y

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: > > > >

[PATCH 15/19] staging: lustre: use explicit poll loop in ptlrpc_service_unlink_rqbd

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

[PATCH 13/19] staging: lustre: use wait_event_idle_timeout in ptlrpcd()

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 ---

[PATCH 14/19] staging: lustre: improve waiting in sptlrpc_req_refresh_ctx

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

[PATCH 17/19] staging: lustre: remove l_wait_event from ptlrpc_set_wait

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

[PATCH 16/19] staging: lustre: use explicit poll loop in ptlrpc_unregister_reply

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

[PATCH 12/19] staging: lustre: make polling loop in ptlrpc_unregister_bulk more obvious

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(+),

[PATCH 11/19] staging: lustre: remove back_to_sleep()

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

[PATCH 5 v2: 00/19] staging: lustre: use standard wait_event macros

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

[PATCH 02/19] staging: lustre: discard SVC_SIGNAL and related functions

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

[PATCH 08/19] staging: lustre: simplify waiting in ldlm_completion_ast()

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

[PATCH 09/19] staging: lustre: open code polling loop instead of using l_wait_event()

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

[PATCH 10/19] staging: lustre: simplify waiting in ptlrpc_invalidate_import()

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.

[PATCH 07/19] staging: lustre: simplify l_wait_event when intr handler but no timeout.

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

Re: [PATCH V3 2/2] cpufreq: imx6q: add 696MHz operating point for i.mx6ul

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:

Re: [BUG] schedutil governor produces regular max freq spikes because of lockup detector watchdog threads

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 >

Re: [PATCH] make RUNTIME_TESTS a menuconfig to ease disabling it all

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.

Re: [PATCH v4 14/16] phy: Add USB speed related PHY modes

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(>mutex); >> +ret = phy->ops->get_mode(phy); >

[PATCH] Staging: greybus: Fix multiple checks for null pointers

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(-)

[PATCH 1/2] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs

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

[PATCH 2/2] arm64: Branch predictor hardening for Cavium ThunderX2

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

Re: [patch V2 2/2] x86/cpu: Implement CPU vulnerabilites sysfs functions

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

Re: Linux 4.15-rc7

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

[PATCH 03/19] staging: lustre: replace simple cases of l_wait_event() with wait_event().

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

[PATCH 06/19] staging: lustre: introduce and use l_wait_event_abortable()

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

[PATCH 01/19] sched/wait: add wait_event_idle() functions.

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()

[PATCH 05/19] staging: lustre: use wait_event_idle_timeout() where appropriate.

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

[PATCH 04/19] staging: lustre: discard cfs_time_seconds()

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 ++--

Re: metag build error in -next due to 'fs, elf: drop MAP_FIXED usage from elf_map'

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': > >

Re: [PATCH v4 6/7] ARM: davinci: convert to common clock framework

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

Re: [PATCH] pinctrl: mcp23s08: fix irq setup order

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

Re: [PATCH] rtc: Fix overflow when converting time64_t to rtc_time

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

RE: [PATCH] KVM: VMX: use same MSR bitmaps for 32-/64-bit modes, fix MSR bitmaps for processor tracing

> -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

Re: [PATCH v5 2/7] scsi: libsas: shut down the PHY if events reached the threshold

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 >>

Re: [PATCH 06/18] x86, barrier: stop speculation for failed access_ok

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: > > > >

[PATCH 18/19] staging: lustre: replace l_wait_event_exclusive_head() with wait_event_idle_exclusive

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

[PATCH 19/19] staging: lustre: remove l_wait_event() and related code

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

[PATCH] power: reset: msm: Clarify restart and poweroff

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

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

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

Re: [PATCH V8 3/3] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

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

[PATCH 5/6] arm64: tegra: Add Tegra194 chip device tree

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

Re: [PATCH v3 01/13] x86/retpoline: Add initial retpoline support

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,

[PATCH v3] ftrace/module: Move ftrace_release_mod() to ddebug_cleanup label

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

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

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

[PATCH 1/7] pipe, sysctl: drop 'min' parameter from pipe-max-size converter

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

[PATCH 3/3] rtc: Add one offset seconds to expand RTC range

>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

[PATCH 2/3] rtc: Factor out the RTC range validation into rtc_valid_range()

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

[PATCH 1/3] rtc: Use time64_t to save range_max of RTC

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

<    1   2   3   4   5   6   7   8   9   >