[PATCH -tip v3 3/7] x86: kprobes: Remove jprobe implementation

Remove arch dependent setjump/longjump functions and unused fields in kprobe_ctlblk for jprobes. Signed-off-by: Masami Hiramatsu --- arch/x86/include/asm/kprobes.h |3 - arch/x86/kernel/kprobes/core.c | 87 2 files changed, 90

[PATCH -tip v3 4/7] kprobes: Ignore break_handler

Ignore break_handler related code because it was only used by jprobe and jprobe is removed. Signed-off-by: Masami Hiramatsu --- Documentation/kprobes.txt |2 +- kernel/kprobes.c | 39 +-- 2 files changed, 6 insertions(+),

[PATCH -tip v3 3/7] x86: kprobes: Remove jprobe implementation

Remove arch dependent setjump/longjump functions and unused fields in kprobe_ctlblk for jprobes. Signed-off-by: Masami Hiramatsu --- arch/x86/include/asm/kprobes.h |3 - arch/x86/kernel/kprobes/core.c | 87 2 files changed, 90 deletions(-) diff

[PATCH -tip v3 4/7] kprobes: Ignore break_handler

Ignore break_handler related code because it was only used by jprobe and jprobe is removed. Signed-off-by: Masami Hiramatsu --- Documentation/kprobes.txt |2 +- kernel/kprobes.c | 39 +-- 2 files changed, 6 insertions(+), 35 deletions(-) diff

[PATCH -tip v3 1/7] Documentation/kprobes: Fix to remove remaining jprobe

Remove jps from the document, since jprobe is removed. Signed-off-by: Masami Hiramatsu --- Documentation/kprobes.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 22208bf2386d..5ae80baf3921

[PATCH -tip v3 1/7] Documentation/kprobes: Fix to remove remaining jprobe

Remove jps from the document, since jprobe is removed. Signed-off-by: Masami Hiramatsu --- Documentation/kprobes.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 22208bf2386d..5ae80baf3921 100644 ---

[PATCH -tip v3 2/7] kprobes: Remove jprobe API implementation

Remove jprobe API implementations and test cases for those APIs which is no more used. Signed-off-by: Masami Hiramatsu --- Changes in v3: - Remove test cases. --- include/linux/kprobes.h |3 -- kernel/kprobes.c| 78 +--

[PATCH -tip v3 2/7] kprobes: Remove jprobe API implementation

Remove jprobe API implementations and test cases for those APIs which is no more used. Signed-off-by: Masami Hiramatsu --- Changes in v3: - Remove test cases. --- include/linux/kprobes.h |3 -- kernel/kprobes.c| 78 +-- kernel/test_kprobes.c

[PATCH -tip v3 0/7] kprobes: x86: Cleanup jprobe implementation on x86

Hello, Since we decided to remove jprobe from kernel last year, its APIs are disabled and we worked on moving in-kernel jprobe users to kprobes or trace-events. And now no jprobe users are here anymore. This is the 3rd version of the series for removing jprobe from x86 and generic code. V2 is

[PATCH -tip v3 0/7] kprobes: x86: Cleanup jprobe implementation on x86

Hello, Since we decided to remove jprobe from kernel last year, its APIs are disabled and we worked on moving in-kernel jprobe users to kprobes or trace-events. And now no jprobe users are here anymore. This is the 3rd version of the series for removing jprobe from x86 and generic code. V2 is

[PATCH 01/14] fpga: region: don't use drvdata in common fpga code

Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution has to create an

[PATCH 01/14] fpga: region: don't use drvdata in common fpga code

Changes to fpga_region_register function to not set drvdata. Setting drvdata is fine for DT based devices that will have one region per platform device. However PCIe based devices may have multiple FPGA regions under one PCIe device. Without these changes, the PCIe solution has to create an

[PATCH 02/14] fpga: manager: change api, don't use drvdata

Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only parameter. struct fpga_manager

[PATCH 08/14] fpga: region: kernel-doc fixes

Fix formatting and some cleanup for the kernel-doc documentation in fpga-region.c Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c index

[PATCH 05/14] fpga: use SPDX

Replace GPLv2 boilerplate with SPDX in FPGA code that came from me or from Altera. Signed-off-by: Alan Tull --- drivers/fpga/altera-fpga2sdram.c | 13 + drivers/fpga/altera-freeze-bridge.c| 13 + drivers/fpga/altera-hps2fpga.c | 13

[PATCH 06/14] fpga: mgr: kernel-doc fixes

Clean up the kernel-doc documentation in fpga-mgr.c and fix the following warnings when documentation is built: ./drivers/fpga/fpga-mgr.c:252: warning: Function parameter or member 'info' not described in 'fpga_mgr_buf_load' ./drivers/fpga/fpga-mgr.c:252: warning: Excess function parameter

[PATCH 05/14] fpga: use SPDX

Replace GPLv2 boilerplate with SPDX in FPGA code that came from me or from Altera. Signed-off-by: Alan Tull --- drivers/fpga/altera-fpga2sdram.c | 13 + drivers/fpga/altera-freeze-bridge.c| 13 + drivers/fpga/altera-hps2fpga.c | 13 +

[PATCH 06/14] fpga: mgr: kernel-doc fixes

Clean up the kernel-doc documentation in fpga-mgr.c and fix the following warnings when documentation is built: ./drivers/fpga/fpga-mgr.c:252: warning: Function parameter or member 'info' not described in 'fpga_mgr_buf_load' ./drivers/fpga/fpga-mgr.c:252: warning: Excess function parameter

[PATCH 02/14] fpga: manager: change api, don't use drvdata

Change fpga_mgr_register to not set or use drvdata. This supports the case where a PCIe device has more than one manager. Add fpga_mgr_create/free functions. Change fpga_mgr_register and fpga_mgr_unregister functions to take the mgr struct as their only parameter. struct fpga_manager

[PATCH 08/14] fpga: region: kernel-doc fixes

Fix formatting and some cleanup for the kernel-doc documentation in fpga-region.c Signed-off-by: Alan Tull --- drivers/fpga/fpga-region.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/fpga/fpga-region.c b/drivers/fpga/fpga-region.c index 0878f62..112fa3a

[PATCH 07/14] fpga: bridge: kernel-doc fixes

Fix the following warnings when documentation is built: ./drivers/fpga/fpga-bridge.c:143: warning: Function parameter or member 'info' not described in 'fpga_bridge_get' ./drivers/fpga/fpga-bridge.c:1: warning: no structured comments found Signed-off-by: Alan Tull ---

[PATCH 07/14] fpga: bridge: kernel-doc fixes

Fix the following warnings when documentation is built: ./drivers/fpga/fpga-bridge.c:143: warning: Function parameter or member 'info' not described in 'fpga_bridge_get' ./drivers/fpga/fpga-bridge.c:1: warning: no structured comments found Signed-off-by: Alan Tull ---

[PATCH 10/14] documentation: fpga: move fpga-mgr.txt to driver-api

Move Documentation/fpga/fpga-mgr.txt to driver-api/fpga/fpga-mgr.rst and: - Add to driver-api/fpga/index.rst - Format changes so documentation builds cleanly. - Minor rewrites that make the doc flow better as ReST documentation. - Such as moving API reference to end of doc - Change API

[PATCH 10/14] documentation: fpga: move fpga-mgr.txt to driver-api

Move Documentation/fpga/fpga-mgr.txt to driver-api/fpga/fpga-mgr.rst and: - Add to driver-api/fpga/index.rst - Format changes so documentation builds cleanly. - Minor rewrites that make the doc flow better as ReST documentation. - Such as moving API reference to end of doc - Change API

[PATCH 09/14] Documentation: fpga: move fpga overview to driver-api

Start of moving Documentation/fpga/*.txt to driver-api, including: - Add new directory driver-api/fpga - Add new file driver-api/fpga/index.rst - Add driver-api/fpga to driver-api/index.rst - Move Documentation/fpga/overview.txt to driver-api/fpga/intro.rst - Formatting and rewrites so that

[PATCH 03/14] fpga: bridge: change api, don't use drvdata

Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the only parameter. struct fpga_bridge

[PATCH 09/14] Documentation: fpga: move fpga overview to driver-api

Start of moving Documentation/fpga/*.txt to driver-api, including: - Add new directory driver-api/fpga - Add new file driver-api/fpga/index.rst - Add driver-api/fpga to driver-api/index.rst - Move Documentation/fpga/overview.txt to driver-api/fpga/intro.rst - Formatting and rewrites so that

[PATCH 03/14] fpga: bridge: change api, don't use drvdata

Change fpga_bridge_register to not set drvdata. This is to support the case where a PCIe device can have more than one bridge. Add API functions to create/free the fpga bridge struct. Change fpga_bridge_register/unregister to take FPGA bridge struct as the only parameter. struct fpga_bridge

[PATCH 12/14] documentation: fpga: move fpga-region.txt to driver-api

Move Documentation/fpga/fpga-region.txt to driver-api/fpga/fpga-region.rst. Including: - Add it to driver-api/fpga/index.rst - Formatting changes to build cleanly as ReST documentation - Some rewrites for better flow as a ReST doc such as moving API reference to the end of the doc -

[PATCH 12/14] documentation: fpga: move fpga-region.txt to driver-api

Move Documentation/fpga/fpga-region.txt to driver-api/fpga/fpga-region.rst. Including: - Add it to driver-api/fpga/index.rst - Formatting changes to build cleanly as ReST documentation - Some rewrites for better flow as a ReST doc such as moving API reference to the end of the doc -

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

+ Kishon Hi, On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead

[PATCH 11/14] documentation: fpga: add bridge document to driver-api

Add a new document to driver-api/fpga that documents the fpga bridge API and add it to driver-api/fpga/index.rst Signed-off-by: Alan Tull --- Documentation/driver-api/fpga/fpga-bridge.rst | 49 +++ Documentation/driver-api/fpga/index.rst | 1 + 2

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

+ Kishon Hi, On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead

[PATCH 11/14] documentation: fpga: add bridge document to driver-api

Add a new document to driver-api/fpga that documents the fpga bridge API and add it to driver-api/fpga/index.rst Signed-off-by: Alan Tull --- Documentation/driver-api/fpga/fpga-bridge.rst | 49 +++ Documentation/driver-api/fpga/index.rst | 1 + 2 files changed, 50

[PATCH 13/14] fpga: clarify that unregister functions also free

The following functions also free the struct. Add that fact to the function documentation. - fpga_mgr_free - fpga_bridge_free - fpga_region_free Signed-off-by: Alan Tull --- drivers/fpga/fpga-bridge.c | 2 +- drivers/fpga/fpga-mgr.c| 2 +- drivers/fpga/fpga-region.c |

[PATCH 04/14] fpga: region: change api, add fpga_region_create/free

Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct fpga_manager *mgr,

[PATCH 04/14] fpga: region: change api, add fpga_region_create/free

Add fpga_region_create/free API functions. Change fpga_region_register to take FPGA region struct as the only parameter. Change fpga_region_unregister to return void. struct fpga_region *fpga_region_create(struct device *dev, struct fpga_manager *mgr,

[PATCH 13/14] fpga: clarify that unregister functions also free

The following functions also free the struct. Add that fact to the function documentation. - fpga_mgr_free - fpga_bridge_free - fpga_region_free Signed-off-by: Alan Tull --- drivers/fpga/fpga-bridge.c | 2 +- drivers/fpga/fpga-mgr.c| 2 +- drivers/fpga/fpga-region.c | 2 +- 3 files

[PATCH 14/14] MAINTAINERS: Add driver-api/fpga path

Add Documentation/driver-api/fpga path to MAINTAINERS file for fpga. Signed-off-by: Alan Tull --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9ce5062..febeecd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5612,6 +5612,7 @@

[PATCH 14/14] MAINTAINERS: Add driver-api/fpga path

Add Documentation/driver-api/fpga path to MAINTAINERS file for fpga. Signed-off-by: Alan Tull --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9ce5062..febeecd 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5612,6 +5612,7 @@ S:

[PATCH 00/14] fpga api changes and kernel-doc fixup

I'm posting these all together because they are interdependent. Patches 1-4 are a repost of v4 of the FPGA api change. Patch 5 is a repost of adding SPDX to my fpga code Patch 6-12 update the fpga kernel-doc documentation and move existing .txt fpga documentation to driver-api ReST documents.

[PATCH 00/14] fpga api changes and kernel-doc fixup

I'm posting these all together because they are interdependent. Patches 1-4 are a repost of v4 of the FPGA api change. Patch 5 is a repost of adding SPDX to my fpga code Patch 6-12 update the fpga kernel-doc documentation and move existing .txt fpga documentation to driver-api ReST documents.

Re: [PATCH 4.4 60/97] clk: mvebu: armada-38x: add support for 1866MHz variants

On Thu, 2018-05-17 at 00:32 +0100, Ben Hutchings wrote: [...] > ...but this only adds entries to the lookup table at indexes 9-12 > inclusive. > > It looks like this fixes the clock settings, but not the warning. Sorry, I misread this, it's fine. Ben. -- Ben Hutchings Software Developer,

Re: [PATCH 4.4 60/97] clk: mvebu: armada-38x: add support for 1866MHz variants

On Thu, 2018-05-17 at 00:32 +0100, Ben Hutchings wrote: [...] > ...but this only adds entries to the lookup table at indexes 9-12 > inclusive. > > It looks like this fixes the clock settings, but not the warning. Sorry, I misread this, it's fine. Ben. -- Ben Hutchings Software Developer,

[PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces

ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates a pud / pmd map. The following preconditions are met at their entry. - All pte entries for a target pud/pmd address range have been cleared. - System-wide TLB purges have been peformed for a target pud/pmd address

[PATCH v3 3/3] x86/mm: add TLB purge to free pmd/pte page interfaces

ioremap() calls pud_free_pmd_page() / pmd_free_pte_page() when it creates a pud / pmd map. The following preconditions are met at their entry. - All pte entries for a target pud/pmd address range have been cleared. - System-wide TLB purges have been peformed for a target pud/pmd address

[PATCH v3 1/3] x86/mm: disable ioremap free page handling on x86-PAE

ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd tables are not shared among processes on x86-PAE. Therefore, any update to sync'd pmd entries need re-syncing. Freeing a pte page also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one(). Disable free page

[PATCH v3 1/3] x86/mm: disable ioremap free page handling on x86-PAE

ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd tables are not shared among processes on x86-PAE. Therefore, any update to sync'd pmd entries need re-syncing. Freeing a pte page also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one(). Disable free page

[PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr

From: Chintan Pandya This patch ("mm/vmalloc: Add interfaces to free unmapped page table") adds following 2 interfaces to free the page table in case we implement huge mapping. pud_free_pmd_page() and pmd_free_pte_page() Some architectures (like arm64) needs to do

[PATCH v3 2/3] ioremap: Update pgtable free interfaces with addr

From: Chintan Pandya This patch ("mm/vmalloc: Add interfaces to free unmapped page table") adds following 2 interfaces to free the page table in case we implement huge mapping. pud_free_pmd_page() and pmd_free_pte_page() Some architectures (like arm64) needs to do proper TLB maintanance after

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

[PATCH v3 0/3] fix free pmd/pte page handlings on x86

This series fixes two issues in the x86 ioremap free page handlings for pud/pmd mappings. Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables the free page handling on x86-PAE. Patch 02-03 fixes a possible issue with speculation which can cause stale page-directory cache. - Patch

[PATCH v3 0/3] fix free pmd/pte page handlings on x86

This series fixes two issues in the x86 ioremap free page handlings for pud/pmd mappings. Patch 01 fixes BUG_ON on x86-PAE reported by Joerg. It disables the free page handling on x86-PAE. Patch 02-03 fixes a possible issue with speculation which can cause stale page-directory cache. - Patch

Re: [PATCH 4.4 60/97] clk: mvebu: armada-38x: add support for 1866MHz variants

On Sun, 2018-04-22 at 15:53 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Ralph Sennhauser > > commit 9593f4f56cf5d1c443f0a0c7f01de38f979d upstream. > > The

Re: [PATCH 4.4 60/97] clk: mvebu: armada-38x: add support for 1866MHz variants

On Sun, 2018-04-22 at 15:53 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch.  If anyone has any objections, please let me know. > > -- > > From: Ralph Sennhauser > > commit 9593f4f56cf5d1c443f0a0c7f01de38f979d upstream. > > The Linksys WRT3200ACM CPU is clocked

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 11:08, Stephen Boyd wrote: Quoting risha...@codeaurora.org (2018-05-16 10:33:14) On 2018-05-16 10:03, Stephen Boyd wrote: > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) >> + >> +- max-slices: >> + usage: required >> + Value Type: >> + Definition: Number of

Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc

On 2018-05-16 11:08, Stephen Boyd wrote: Quoting risha...@codeaurora.org (2018-05-16 10:33:14) On 2018-05-16 10:03, Stephen Boyd wrote: > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00) >> + >> +- max-slices: >> + usage: required >> + Value Type: >> + Definition: Number of

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead of relying on

Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware

On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead of relying on

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

On Wed, May 16, 2018 at 04:09:29PM -0700, H. Peter Anvin wrote: > On 05/16/18 08:49, Dave Martin wrote: > > > > Since only contains #defines, it may be enough for arch > > headers to include . > > > > doesn't seem to have any reason to exist at all. If > anyone includes it now, they are

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

On Wed, May 16, 2018 at 04:09:29PM -0700, H. Peter Anvin wrote: > On 05/16/18 08:49, Dave Martin wrote: > > > > Since only contains #defines, it may be enough for arch > > headers to include . > > > > doesn't seem to have any reason to exist at all. If > anyone includes it now, they are

Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works

On Wed, May 16, 2018 at 08:45:43AM -0700, Paul E. McKenney wrote: [...] > > > > The code would be correct then, but one issue is it would shout out the > > > > 'Prestarted' tracepoint for 'c' when that's not really true.. > > > > > > > >rcu_seq_done(_root->gp_seq, c) > > > > > >

Re: [PATCH RFC 1/8] rcu: Add comment documenting how rcu_seq_snap works

On Wed, May 16, 2018 at 08:45:43AM -0700, Paul E. McKenney wrote: [...] > > > > The code would be correct then, but one issue is it would shout out the > > > > 'Prestarted' tracepoint for 'c' when that's not really true.. > > > > > > > >rcu_seq_done(_root->gp_seq, c) > > > > > >

Re: [PATCH v2 11/14] ftrace/selftest: Have the reset_trigger code be a bit more careful

On Wed, 16 May 2018 10:00:04 -0400 Steven Rostedt wrote: > On Wed, 16 May 2018 21:53:50 +0900 > Masami Hiramatsu wrote: > > > On Mon, 14 May 2018 16:58:56 -0400 > > Steven Rostedt wrote: > > > > > From: "Steven Rostedt (VMware)"

Re: [PATCH v2 11/14] ftrace/selftest: Have the reset_trigger code be a bit more careful

On Wed, 16 May 2018 10:00:04 -0400 Steven Rostedt wrote: > On Wed, 16 May 2018 21:53:50 +0900 > Masami Hiramatsu wrote: > > > On Mon, 14 May 2018 16:58:56 -0400 > > Steven Rostedt wrote: > > > > > From: "Steven Rostedt (VMware)" > > > > > > The trigger code is picky in how it can be

Re: [PATCH RFC 6/8] rcu: Add back the Startedleaf tracepoint

On Wed, May 16, 2018 at 08:48:29AM -0700, Paul E. McKenney wrote: > On Tue, May 15, 2018 at 04:04:30PM -0700, Joel Fernandes wrote: > > On Mon, May 14, 2018 at 08:46:03PM -0700, Paul E. McKenney wrote: > > > On Mon, May 14, 2018 at 05:57:09PM -0700, Joel Fernandes wrote: > > > > On Mon, May 14,

Re: [PATCH RFC 6/8] rcu: Add back the Startedleaf tracepoint

On Wed, May 16, 2018 at 08:48:29AM -0700, Paul E. McKenney wrote: > On Tue, May 15, 2018 at 04:04:30PM -0700, Joel Fernandes wrote: > > On Mon, May 14, 2018 at 08:46:03PM -0700, Paul E. McKenney wrote: > > > On Mon, May 14, 2018 at 05:57:09PM -0700, Joel Fernandes wrote: > > > > On Mon, May 14,

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Proposal

Hello Greetings to you please i have a business proposal for you contact me for more detailes asap thanks. Best Regards, Miss.Zeliha ömer faruk Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey

Re: [PATCH] Revert "powerpc/64: Fix checksum folding in csum_add()"

On Tue, Apr 10, 2018 at 08:34:37AM +0200, Christophe Leroy wrote: > This reverts commit 6ad966d7303b70165228dba1ee8da1a05c10eefe. > > That commit was pointless, because csum_add() sums two 32 bits > values, so the sum is 0x1fffe at the maximum. > And then when adding upper part (1) and lower

Re: [PATCH] Revert "powerpc/64: Fix checksum folding in csum_add()"

On Tue, Apr 10, 2018 at 08:34:37AM +0200, Christophe Leroy wrote: > This reverts commit 6ad966d7303b70165228dba1ee8da1a05c10eefe. > > That commit was pointless, because csum_add() sums two 32 bits > values, so the sum is 0x1fffe at the maximum. > And then when adding upper part (1) and lower

[PATCH 1/1] linux-firmware: Update AMD cpu microcode

* Add AMD cpu microcode for processor family 17h * Update AMD cpu microcode for processor family 15h * Update the AMD cpu microcode license copyright * Add a Version for both microcode family 15h and 17h Key Name= AMD Microcode Signing Key (for signing microcode container files only) Key

[PATCH 1/1] linux-firmware: Update AMD cpu microcode

* Add AMD cpu microcode for processor family 17h * Update AMD cpu microcode for processor family 15h * Update the AMD cpu microcode license copyright * Add a Version for both microcode family 15h and 17h Key Name= AMD Microcode Signing Key (for signing microcode container files only) Key

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

On 05/16/18 08:49, Dave Martin wrote: > > Since only contains #defines, it may be enough for arch > headers to include . > doesn't seem to have any reason to exist at all. If anyone includes it now, they are Doing It Wrong[TM] since includes . -hpa

Re: [RFC PATCH] UAPI: Document auxvec AT_* namespace policy and note reservations

On 05/16/18 08:49, Dave Martin wrote: > > Since only contains #defines, it may be enough for arch > headers to include . > doesn't seem to have any reason to exist at all. If anyone includes it now, they are Doing It Wrong[TM] since includes . -hpa

Re: [PATCH] PCI: DPC: Clear AER status bits before disabling port containment

On Wed, May 16, 2018 at 06:44:22PM -0400, Sinan Kaya wrote: > On 5/16/2018 5:33 PM, Alexandru Gagniuc wrote: > > AER status bits are sticky, and they survive system resets. Downstream > > devices are usually taken care of after re-enumerating the downstream > > busses, as the AER bits are cleared

Re: [PATCH] PCI: DPC: Clear AER status bits before disabling port containment

On Wed, May 16, 2018 at 06:44:22PM -0400, Sinan Kaya wrote: > On 5/16/2018 5:33 PM, Alexandru Gagniuc wrote: > > AER status bits are sticky, and they survive system resets. Downstream > > devices are usually taken care of after re-enumerating the downstream > > busses, as the AER bits are cleared

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

Thanks Thomas! I've attached the dmesg output with the kernel parameter and supplied patch. Here is the excerpt of the ftrace dump: Dumping ftrace buffer: - swapper/-1   0d... 463331us : __x2apic_send_IPI_mask: To: swapper/-1   0d... 46us :

Re: [bisected] rcu_sched detected stalls - 4.15 or newer kernel with some Xeon skylake CPUs and extended APIC

Thanks Thomas! I've attached the dmesg output with the kernel parameter and supplied patch. Here is the excerpt of the ftrace dump: Dumping ftrace buffer: - swapper/-1   0d... 463331us : __x2apic_send_IPI_mask: To: swapper/-1   0d... 46us :

Re: [PATCH] bpf: add __printf verification to bpf_verifier_vlog

On 05/16/2018 10:27 PM, Mathieu Malaterre wrote: > __printf is useful to verify format and arguments. ‘bpf_verifier_vlog’ > function is used twice in verifier.c in both cases the caller function > already uses the __printf gcc attribute. > > Remove the following warning, triggered with W=1: > >

Re: [PATCH] bpf: add __printf verification to bpf_verifier_vlog

On 05/16/2018 10:27 PM, Mathieu Malaterre wrote: > __printf is useful to verify format and arguments. ‘bpf_verifier_vlog’ > function is used twice in verifier.c in both cases the caller function > already uses the __printf gcc attribute. > > Remove the following warning, triggered with W=1: > >

linux-next: manual merge of the renesas tree with the mvebu tree

Hi all, Today's linux-next merge of the renesas tree got a conflict in: arch/arm/configs/multi_v7_defconfig between commit: 873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration") from the mvebu tree and commits: 57eec170e954 ("ARM: multi_v7_defconfig: Disable

linux-next: manual merge of the renesas tree with the mvebu tree

Hi all, Today's linux-next merge of the renesas tree got a conflict in: arch/arm/configs/multi_v7_defconfig between commit: 873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration") from the mvebu tree and commits: 57eec170e954 ("ARM: multi_v7_defconfig: Disable

[PATCH] PM / devfreq: Init user limits from OPP limits, not viceversa

Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") introduced the initialization of the user limits min/max_freq from the lowest/highest available OPPs. Later commit f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") added scaling_min/max_freq,

[PATCH] PM / devfreq: Init user limits from OPP limits, not viceversa

Commit ab8f58ad72c4 ("PM / devfreq: Set min/max_freq when adding the devfreq device") introduced the initialization of the user limits min/max_freq from the lowest/highest available OPPs. Later commit f1d981eaecf8 ("PM / devfreq: Use the available min/max frequency") added scaling_min/max_freq,

linux-next: manual merge of the mvebu tree with the arm-soc tree

Hi all, Today's linux-next merge of the mvebu tree got a conflict in: arch/arm/configs/multi_v7_defconfig between various commits from the arm-soc tree and commit: 873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration") from the mvebu tree. I fixed it up (see below)

linux-next: manual merge of the mvebu tree with the arm-soc tree

Hi all, Today's linux-next merge of the mvebu tree got a conflict in: arch/arm/configs/multi_v7_defconfig between various commits from the arm-soc tree and commit: 873edb2930ef ("ARM: multi_v7_defconfig: Update with current configuration") from the mvebu tree. I fixed it up (see below)

Re: [PATCH] regulator: core: Allow for regulators that can't be read at bootup

On 05/15/2018 03:07 PM, Douglas Anderson wrote: > As discussed in the patches to try to support the RPMh regulators [1], > the fact that regulators are write-only means that its driver's > get_voltage_sel() should return an error code if it's called before > any calls to set_voltage_sel(). This

Re: [PATCH] regulator: core: Allow for regulators that can't be read at bootup

On 05/15/2018 03:07 PM, Douglas Anderson wrote: > As discussed in the patches to try to support the RPMh regulators [1], > the fact that regulators are write-only means that its driver's > get_voltage_sel() should return an error code if it's called before > any calls to set_voltage_sel(). This

Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block

On Tue, May 15, 2018 at 11:39:54AM +0200, Johannes Hirte wrote: > The out-of-bound access happens in get_block_address: > > if (bankp && bankp->blocks) { > struct threshold_block *blockp blockp = >blocks[block]; > > with block=1. This doesn't exists. I don't even find any

Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block

On Tue, May 15, 2018 at 11:39:54AM +0200, Johannes Hirte wrote: > The out-of-bound access happens in get_block_address: > > if (bankp && bankp->blocks) { > struct threshold_block *blockp blockp = >blocks[block]; > > with block=1. This doesn't exists. I don't even find any

[PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked

Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling delay of the irq_work and the wake up of the schedutil governor kthread. A very bad scenario is when a schedutil

[PATCH RFC] schedutil: Allow cpufreq requests to be made even when kthread kicked

Currently there is a chance of a schedutil cpufreq update request to be dropped if there is a pending update request. This pending request can be delayed if there is a scheduling delay of the irq_work and the wake up of the schedutil governor kthread. A very bad scenario is when a schedutil

Re: [PATCH] PCI: DPC: Clear AER status bits before disabling port containment

On 5/16/2018 5:33 PM, Alexandru Gagniuc wrote: > AER status bits are sticky, and they survive system resets. Downstream > devices are usually taken care of after re-enumerating the downstream > busses, as the AER bits are cleared during probe(). > > However, nothing clears the bits of the port

Re: kernel BUG at lib/string.c:LINE! (4)

Hello, On Wed, 16 May 2018, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=16e9101780 > kernel

Re: [PATCH] PCI: DPC: Clear AER status bits before disabling port containment

On 5/16/2018 5:33 PM, Alexandru Gagniuc wrote: > AER status bits are sticky, and they survive system resets. Downstream > devices are usually taken care of after re-enumerating the downstream > busses, as the AER bits are cleared during probe(). > > However, nothing clears the bits of the port

Re: kernel BUG at lib/string.c:LINE! (4)

Hello, On Wed, 16 May 2018, syzbot wrote: > Hello, > > syzbot found the following crash on: > > HEAD commit:0b7d9978406f Merge branch 'Microsemi-Ocelot-Ethernet-switc.. > git tree: net-next > console output: https://syzkaller.appspot.com/x/log.txt?x=16e9101780 > kernel

[PATCH][SMB3] Add ftrace support

I plan to add various tracepoints to cifs.ko, but wanted to verify that the initial patch looks ok (which only adds logging for one event, write errors), before I start adding various other tracepoints. Also I need to know ... is the size of log entries a problem? I have to weight logging just

[PATCH][SMB3] Add ftrace support

I plan to add various tracepoints to cifs.ko, but wanted to verify that the initial patch looks ok (which only adds logging for one event, write errors), before I start adding various other tracepoints. Also I need to know ... is the size of log entries a problem? I have to weight logging just

<    1   2   3   4   5   6   7   8   9   10   >