Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

Op 16-12-16 om 14:17 schreef Nicolai Hähnle: > On 06.12.2016 16:25, Peter Zijlstra wrote: >> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: >> >>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, >>> unsigned int subclass, >>> struct mutex_waiter

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

Op 16-12-16 om 14:17 schreef Nicolai Hähnle: > On 06.12.2016 16:25, Peter Zijlstra wrote: >> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote: >> >>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, >>> unsigned int subclass, >>> struct mutex_waiter

Re: [RFC PATCH 06/14] sparc64: general shared context tsb creation and support

Hi Mike > --- a/arch/sparc/mm/hugetlbpage.c > +++ b/arch/sparc/mm/hugetlbpage.c > @@ -162,8 +162,14 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long > addr, > { > pte_t orig; > > - if (!pte_present(*ptep) && pte_present(entry)) > -

Re: [RFC PATCH 06/14] sparc64: general shared context tsb creation and support

Hi Mike > --- a/arch/sparc/mm/hugetlbpage.c > +++ b/arch/sparc/mm/hugetlbpage.c > @@ -162,8 +162,14 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long > addr, > { > pte_t orig; > > - if (!pte_present(*ptep) && pte_present(entry)) > -

Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

Hi Mike > diff --git a/arch/sparc/kernel/fpu_traps.S b/arch/sparc/kernel/fpu_traps.S > index 336d275..f85a034 100644 > --- a/arch/sparc/kernel/fpu_traps.S > +++ b/arch/sparc/kernel/fpu_traps.S > @@ -73,6 +73,16 @@ do_fpdis: > ldxa[%g3] ASI_MMU, %g5 > .previous > > +661:

Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

Hi Mike > diff --git a/arch/sparc/kernel/fpu_traps.S b/arch/sparc/kernel/fpu_traps.S > index 336d275..f85a034 100644 > --- a/arch/sparc/kernel/fpu_traps.S > +++ b/arch/sparc/kernel/fpu_traps.S > @@ -73,6 +73,16 @@ do_fpdis: > ldxa[%g3] ASI_MMU, %g5 > .previous > > +661:

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

Hi Mike > diff --git a/arch/sparc/include/asm/mmu_context_64.h > b/arch/sparc/include/asm/mmu_context_64.h > index b84be67..d031799 100644 > --- a/arch/sparc/include/asm/mmu_context_64.h > +++ b/arch/sparc/include/asm/mmu_context_64.h > @@ -35,15 +35,15 @@ void __tsb_context_switch(unsigned long

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

Hi Mike > diff --git a/arch/sparc/include/asm/mmu_context_64.h > b/arch/sparc/include/asm/mmu_context_64.h > index b84be67..d031799 100644 > --- a/arch/sparc/include/asm/mmu_context_64.h > +++ b/arch/sparc/include/asm/mmu_context_64.h > @@ -35,15 +35,15 @@ void __tsb_context_switch(unsigned long

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

Hi Mike. On Fri, Dec 16, 2016 at 10:35:25AM -0800, Mike Kravetz wrote: > Add new fields to the mm_context structure to support shared context. > Instead of a simple context ID, add a pointer to a structure with a > reference count. This is needed as multiple tasks will share the > context ID.

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

Hi Mike. On Fri, Dec 16, 2016 at 10:35:25AM -0800, Mike Kravetz wrote: > Add new fields to the mm_context structure to support shared context. > Instead of a simple context ID, add a pointer to a structure with a > reference count. This is needed as multiple tasks will share the > context ID.

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hi Markus, On 16 December 2016 at 14:38, Markus Reichl wrote: > Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski: >> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote: [ I added Arjun to Cc:, maybe he can help in explaining this issue

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Hi Markus, On 16 December 2016 at 14:38, Markus Reichl wrote: > Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski: >> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote: [ I added Arjun to Cc:, maybe he can help in explaining this issue (unfortunately Inderpal's email is

Re: i2c: xiic: Strange clk_prepare_enable() in xiic_i2c_remove()

On Sat, Dec 17, 2016 at 3:24 AM, Alexey Khoroshilov wrote: > Dear Shubhrajyoti, > > Looking at 36ecbcab84d0 ("i2c: xiic: Implement power management") > it is not clear why clk_prepare_enable(i2c->clk) is required in > xiic_i2c_remove()? 834 ret =

Re: i2c: xiic: Strange clk_prepare_enable() in xiic_i2c_remove()

On Sat, Dec 17, 2016 at 3:24 AM, Alexey Khoroshilov wrote: > Dear Shubhrajyoti, > > Looking at 36ecbcab84d0 ("i2c: xiic: Implement power management") > it is not clear why clk_prepare_enable(i2c->clk) is required in > xiic_i2c_remove()? 834 ret = clk_prepare_enable(i2c->clk); 835

Re: Document accounting of FDs passed over UNIX domain sockets

Hi Michael, On Fri, Dec 16, 2016 at 12:08:33PM +0100, Michael Kerrisk (man-pages) wrote: > Hello Willy, > > Your commit 712f4aad406bb1 ("unix: properly account for FDs passed over > unix sockets" added accounting to ensure that the RLIMIT_NOFILE limit > could not be bypassed when passing file

Re: Document accounting of FDs passed over UNIX domain sockets

Hi Michael, On Fri, Dec 16, 2016 at 12:08:33PM +0100, Michael Kerrisk (man-pages) wrote: > Hello Willy, > > Your commit 712f4aad406bb1 ("unix: properly account for FDs passed over > unix sockets" added accounting to ensure that the RLIMIT_NOFILE limit > could not be bypassed when passing file

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

t;> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's >>> next fixes the issue for me, suggesting a bug may have slipped in there. >>> >>> Not sure how this could be fixed, so reporting the issue for now in case >>> it is not kno

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

t;> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's >>> next fixes the issue for me, suggesting a bug may have slipped in there. >>> >>> Not sure how this could be fixed, so reporting the issue for now in case >>> it is not kno

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

Hi, On Fri, Dec 16, 2016 at 4:59 PM, Brian Norris wrote: > In the pattern of many other devices, support a system-sleep pin > configuration. > > Signed-off-by: Brian Norris > --- > Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

Hi, On Fri, Dec 16, 2016 at 4:59 PM, Brian Norris wrote: > In the pattern of many other devices, support a system-sleep pin > configuration. > > Signed-off-by: Brian Norris > --- > Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++ > drivers/spi/spi-rockchip.c

[RFC][PATCH 1/5 v2] usb: dwc2: Avoid sleeping while holding hsotg->lock

Basically when plugging in various cables in different orders, I'm occasionally seeing the following BUG splat: [ 86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002 [ 86.219164] usb 1-1: USB disconnect, device number 9 [ 86.226845] Preemption disabled at:[ 86.230218] []

[RFC][PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board

I just wanted to re-send my current queue of patches for dwc2 controller on the HiKey board, as my last patchset ended up colliding with a number of changes that landed in the 4.10-rc merge window. I've fixed things up and validated these against HiKey. I also made a small change to one of the

[RFC][PATCH 3/5 v2] usb: dwc2: Force port resume on switching to device mode

From: Chen Yu We've seen failures when switching between host and gadget mode, which was diagnosed as being caused due to the bus being auto-suspended when we switched. So this patch forces a port resume when switching to device mode if the bus is suspended. Cc: Wei Xu

[RFC][PATCH 3/5 v2] usb: dwc2: Force port resume on switching to device mode

From: Chen Yu We've seen failures when switching between host and gadget mode, which was diagnosed as being caused due to the bus being auto-suspended when we switched. So this patch forces a port resume when switching to device mode if the bus is suspended. Cc: Wei Xu Cc: Guodong Xu Cc:

[RFC][PATCH 1/5 v2] usb: dwc2: Avoid sleeping while holding hsotg->lock

Basically when plugging in various cables in different orders, I'm occasionally seeing the following BUG splat: [ 86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002 [ 86.219164] usb 1-1: USB disconnect, device number 9 [ 86.226845] Preemption disabled at:[ 86.230218] []

[RFC][PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board

I just wanted to re-send my current queue of patches for dwc2 controller on the HiKey board, as my last patchset ended up colliding with a number of changes that landed in the 4.10-rc merge window. I've fixed things up and validated these against HiKey. I also made a small change to one of the

[RFC][PATCH 4/5 v2] usb: dwc2: Avoid suspending if we're in gadget mode

I've found when booting HiKey with the usb gadget cable attached if I then try to connect via adb, I get an infinite spew of: dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0) dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0) It seems that the usb

[RFC][PATCH 4/5 v2] usb: dwc2: Avoid suspending if we're in gadget mode

I've found when booting HiKey with the usb gadget cable attached if I then try to connect via adb, I get an infinite spew of: dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0) dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0) It seems that the usb

[RFC][PATCH 2/5 v2] usb: dwc2: Workaround case where GOTGCTL state is wrong

When removing a USB-A to USB-otg adapter cable, we get a change status irq, and then in dwc2_conn_id_status_change, we erroniously see the GOTGCTL_CONID_B flag set. This causes us to get stuck in the "while (!dwc2_is_device_mode(hsotg))" loop, spitting out "Waiting for Peripheral Mode, Mode=Host"

[RFC][PATCH 5/5 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

From: Chen Yu The Hi6220's usb controller is limited in that it does not support "Split Transactions", so it does not support communicating with low-speed and full-speed devices behind a high-speed hub. Thus it requires a quirk so that we can manually drop the usb speed

[RFC][PATCH 5/5 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

From: Chen Yu The Hi6220's usb controller is limited in that it does not support "Split Transactions", so it does not support communicating with low-speed and full-speed devices behind a high-speed hub. Thus it requires a quirk so that we can manually drop the usb speed when low/full-speed are

[RFC][PATCH 2/5 v2] usb: dwc2: Workaround case where GOTGCTL state is wrong

When removing a USB-A to USB-otg adapter cable, we get a change status irq, and then in dwc2_conn_id_status_change, we erroniously see the GOTGCTL_CONID_B flag set. This causes us to get stuck in the "while (!dwc2_is_device_mode(hsotg))" loop, spitting out "Waiting for Peripheral Mode, Mode=Host"

[PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

This patch adds CAP_GROUP and logic to allows a process to migrate other tasks between cgroups. In Android (where this feature originated), the ActivityManager tracks various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM, etc), and then as applications change states, the SchedPolicy

[PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

This patch adds CAP_GROUP and logic to allows a process to migrate other tasks between cgroups. In Android (where this feature originated), the ActivityManager tracks various application states (TOP_APP, FOREGROUND, BACKGROUND, SYSTEM, etc), and then as applications change states, the SchedPolicy

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

On Mon, 12 Dec 2016 17:52:50 +0300 "Kirill A. Shutemov" wrote: > On Thu, Dec 08, 2016 at 01:25:37PM -0500, Jérémy Lefaure wrote: > > On Thu, 8 Dec 2016 13:50:11 +0300 > > "Kirill A. Shutemov" wrote: > > > > > On Wed, Dec 07, 2016 at

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

On Mon, 12 Dec 2016 17:52:50 +0300 "Kirill A. Shutemov" wrote: > On Thu, Dec 08, 2016 at 01:25:37PM -0500, Jérémy Lefaure wrote: > > On Thu, 8 Dec 2016 13:50:11 +0300 > > "Kirill A. Shutemov" wrote: > > > > > On Wed, Dec 07, 2016 at 11:38:33PM -0500, Jérémy Lefaure wrote: > > > > When

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote: >> "Luis R. Rodriguez" writes: >> > kmod has an optimization in place whereby if a some kernel code >> > uses request_module() on a module already loaded we never

Re: [RFC 10/10] kmod: add a sanity check on module loading

"Luis R. Rodriguez" writes: > On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote: >> "Luis R. Rodriguez" writes: >> > kmod has an optimization in place whereby if a some kernel code >> > uses request_module() on a module already loaded we never bother >> > userspace as the module

Re: [GIT PULL] KVM fixes for 4.10 merge window

在 2016/12/17 03:42, Linus Torvalds 写道: On Fri, Dec 16, 2016 at 8:57 AM, Paolo Bonzini wrote: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus This piece-of-shit branch has obviously never been even compile-tested: arch/x86/kernel/kvm.c: In function

Re: [GIT PULL] KVM fixes for 4.10 merge window

在 2016/12/17 03:42, Linus Torvalds 写道: On Fri, Dec 16, 2016 at 8:57 AM, Paolo Bonzini wrote: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus This piece-of-shit branch has obviously never been even compile-tested: arch/x86/kernel/kvm.c: In function

Re: [PATCH] TOMOYO: use designated initializers

Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > > Signed-off-by: Kees Cook

Re: [PATCH] TOMOYO: use designated initializers

Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > > Signed-off-by: Kees Cook

Re: [PATCH 2/2] remoteproc: Remove firmware_loading_complete

On 12/16/2016 11:28 AM, Bjorn Andersson wrote: On Fri 16 Dec 00:26 PST 2016, loic pallardy wrote: On 12/16/2016 01:03 AM, Sarangdhar Joshi wrote: rproc_del() waits on firmware_loading_complete in order to make sure rproc_add() completed successfully before calling rproc_shutdown(). However

Re: [PATCH 2/2] remoteproc: Remove firmware_loading_complete

On 12/16/2016 11:28 AM, Bjorn Andersson wrote: On Fri 16 Dec 00:26 PST 2016, loic pallardy wrote: On 12/16/2016 01:03 AM, Sarangdhar Joshi wrote: rproc_del() waits on firmware_loading_complete in order to make sure rproc_add() completed successfully before calling rproc_shutdown(). However

[PATCH] input: i8042-x86ia64io.h: Add Pegatron touchpad to noloop table

Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able to recognize a synaptics touchpad in the AUX port. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791 (Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B)) Suggested-by: Dmitry Torokhov

[PATCH] input: i8042-x86ia64io.h: Add Pegatron touchpad to noloop table

Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able to recognize a synaptics touchpad in the AUX port. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791 (Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B)) Suggested-by: Dmitry Torokhov Signed-off-by:

Re: [PATCH] ACPICA: use designated initializers

On Sat, Dec 17, 2016 at 2:04 AM, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes >

Re: [PATCH] ACPICA: use designated initializers

On Sat, Dec 17, 2016 at 2:04 AM, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> I already did this. Check my branch. Do you think it should return "u32" (as you currently have it) or "unsigned long"? I thought the latter, since it doesn't cost any more and makes more > I wonder if this could also lead to a similar aliasing > with arch_get_random_int, since I'm pretty

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

> I already did this. Check my branch. Do you think it should return "u32" (as you currently have it) or "unsigned long"? I thought the latter, since it doesn't cost any more and makes more > I wonder if this could also lead to a similar aliasing > with arch_get_random_int, since I'm pretty

Re: [PATCH] acpi: Fix format string type mistakes

On Sat, Dec 17, 2016 at 12:04 AM, Kees Cook wrote: > On Fri, Dec 16, 2016 at 2:36 PM, Rafael J. Wysocki wrote: >> On Fri, Dec 16, 2016 at 10:51 PM, Kees Cook wrote: >>> From: Emese Revfy >>> >>> This adds the

Re: [PATCH] acpi: Fix format string type mistakes

On Sat, Dec 17, 2016 at 12:04 AM, Kees Cook wrote: > On Fri, Dec 16, 2016 at 2:36 PM, Rafael J. Wysocki wrote: >> On Fri, Dec 16, 2016 at 10:51 PM, Kees Cook wrote: >>> From: Emese Revfy >>> >>> This adds the missing __printf attribute which allows compile time >>> format string checking (and

Re: [PATCH] apparmor: use designated initializers

On 12/16/2016 05:04 PM, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > >

Re: [PATCH] apparmor: use designated initializers

On 12/16/2016 05:04 PM, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > >

Re: [GIT pull] x86/cache: Updates for 4.10

On Tue, Dec 13, 2016 at 1:01 AM, Thomas Gleixner wrote: > On Mon, 12 Dec 2016, Linus Torvalds wrote: > >> On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner wrote: >> Ugh, this is some funky stuff. And it's entirely x86-specific, with a >> rather odd special

Re: [GIT pull] x86/cache: Updates for 4.10

On Tue, Dec 13, 2016 at 1:01 AM, Thomas Gleixner wrote: > On Mon, 12 Dec 2016, Linus Torvalds wrote: > >> On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner wrote: >> Ugh, this is some funky stuff. And it's entirely x86-specific, with a >> rather odd special filesystem interface. > > Yes. The

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin wrote: > Ths advice I'd give now is: > - Implement > unsigned long hsiphash(const void *data, size_t len, const unsigned long > key[2]) > .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and >

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin wrote: > Ths advice I'd give now is: > - Implement > unsigned long hsiphash(const void *data, size_t len, const unsigned long > key[2]) > .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and > HalfSipHash on 32-bit. I

Re: [PATCH] platform/x86: fujitsu-laptop: set default trigger for radio LED to rfkill-any

On Fri, Dec 16, 2016 at 03:46:03PM +0100, Micha?? K??pie?? wrote: > The "radio components indicator" LED present in Lifebook E734/E744/E754 > should be lit when any radio transmitter is enabled, so set its default > trigger to rfkill-any. This shouldn't cause any problems. At the end of the day

Re: [PATCH] platform/x86: fujitsu-laptop: set default trigger for radio LED to rfkill-any

On Fri, Dec 16, 2016 at 03:46:03PM +0100, Micha?? K??pie?? wrote: > The "radio components indicator" LED present in Lifebook E734/E744/E754 > should be lit when any radio transmitter is enabled, so set its default > trigger to rfkill-any. This shouldn't cause any problems. At the end of the day

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On 12/15, Pierre-Louis Bossart wrote: > I am not sure I understand this last comment. > init.name is not a constant, it's made of the "pmc_plt_clk_" string > concatenated with an id which directly maps to which hardware clock > is registered. That's all fine. We need globally unique strings for

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

On 12/15, Pierre-Louis Bossart wrote: > I am not sure I understand this last comment. > init.name is not a constant, it's made of the "pmc_plt_clk_" string > concatenated with an id which directly maps to which hardware clock > is registered. That's all fine. We need globally unique strings for

Re: [PATCH v6] soc: qcom: Add SoC info driver

On 12/15, Imran Khan wrote: > On 12/14/2016 5:56 AM, Stephen Boyd wrote: > > On 12/12, Imran Khan wrote: > >> The SoC info driver provides information such as Chip ID, > >> Chip family, serial number and other such details about > >> Qualcomm SoCs. > > > > Yes but why do we care? > > > > We

Re: [PATCH v6] soc: qcom: Add SoC info driver

On 12/15, Imran Khan wrote: > On 12/14/2016 5:56 AM, Stephen Boyd wrote: > > On 12/12, Imran Khan wrote: > >> The SoC info driver provides information such as Chip ID, > >> Chip family, serial number and other such details about > >> Qualcomm SoCs. > > > > Yes but why do we care? > > > > We

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

Am Freitag, 16. Dezember 2016, 14:57:01 CET schrieb Xing Zheng: > Hi Heiko, Doug, > > On 2016年12月16日 02:18, Heiko Stuebner wrote: > > Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson: > >> I still need to digest all of the things that were added to this > >> thread overnight,

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

Am Freitag, 16. Dezember 2016, 14:57:01 CET schrieb Xing Zheng: > Hi Heiko, Doug, > > On 2016年12月16日 02:18, Heiko Stuebner wrote: > > Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson: > >> I still need to digest all of the things that were added to this > >> thread overnight,

Re: Questions on the task isolation patches

On Fri, 16 Dec 2016 16:00:48 -0500 Chris Metcalf wrote: > Sorry for the slow response - I have been busy with some other things. Thanks for the reply. > > On 12/6/2016 4:43 PM, yunhong jiang wrote: > > On Fri, 2 Dec 2016 13:58:08 -0500 > > Chris Metcalf

Re: Questions on the task isolation patches

On Fri, 16 Dec 2016 16:00:48 -0500 Chris Metcalf wrote: > Sorry for the slow response - I have been busy with some other things. Thanks for the reply. > > On 12/6/2016 4:43 PM, yunhong jiang wrote: > > On Fri, 2 Dec 2016 13:58:08 -0500 > > Chris Metcalf wrote: > > > >> On 12/1/2016 5:28 PM,

[PATCH] reiserfs: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] solo6x10: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] apparmor: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] hpsa: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] rbtree: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] TOMOYO: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] scsi/bfa: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] reiserfs: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook --- fs/reiserfs/item_ops.c

[PATCH] solo6x10: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] apparmor: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] hpsa: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook --- drivers/scsi/hpsa.h |

[PATCH] rbtree: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] TOMOYO: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook --- security/tomoyo/file.c

[PATCH] scsi/bfa: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] drm/vmwgfx: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] net/x25: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] drm/nouveau: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] cciss: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] RDMA/nes: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] x86/floppy: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] drm/nouveau: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] cciss: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook --- drivers/block/cciss.h

[PATCH] RDMA/nes: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] x86/floppy: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] drm/vmwgfx: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] net/x25: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] RDMA/i40iw: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

Re: [PATCH] sbus: char: Move D7S_MINOR to include/linux/miscdevice.h

Hi Corentin, On Fri, Dec 16, 2016 at 6:47 AM, Corentin Labbe wrote: > This patch move the define for D7S_MINOR to include/linux/miscdevice.h. > It's better that all minor number are in the same place. > > Signed-off-by: Corentin Labbe > ---

[PATCH] ACPICA: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] video: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

[PATCH] RDMA/i40iw: use designated initializers

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook ---

Re: [PATCH] sbus: char: Move D7S_MINOR to include/linux/miscdevice.h

Hi Corentin, On Fri, Dec 16, 2016 at 6:47 AM, Corentin Labbe wrote: > This patch move the define for D7S_MINOR to include/linux/miscdevice.h. > It's better that all minor number are in the same place. > > Signed-off-by: Corentin Labbe > --- > drivers/sbus/char/display7seg.c | 1 - >

  1   2   3   4   5   6   7   8   9   10   >