Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 10:03:52AM -0400, David Woodhouse wrote: > On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > > I'm not sure I understand the issue.  The public API is not about how > > the driver works.  It doesn't say "don't use DMA API" anywhere, does it? > > It's about

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, Apr 18, 2016 at 10:03:52AM -0400, David Woodhouse wrote: > On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > > I'm not sure I understand the issue.  The public API is not about how > > the driver works.  It doesn't say "don't use DMA API" anywhere, does it? > > It's about

[PATCHv7 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

[PATCHv7 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

Re: [PATCH] Axi-usb: Add support for 64-bit addressing.

On Sun, Apr 17, 2016 at 03:14:34PM +0200, Arnd Bergmann wrote: > On Tuesday 12 April 2016 09:03:38 Rob Herring wrote: > > On Mon, Apr 11, 2016 at 01:11:46PM +0530, Nava kishore Manne wrote: > > > This patch updates the driver to support 64-bit DMA > > > addressing. > > > > > > Signed-off-by: Nava

Re: [PATCH] Axi-usb: Add support for 64-bit addressing.

On Sun, Apr 17, 2016 at 03:14:34PM +0200, Arnd Bergmann wrote: > On Tuesday 12 April 2016 09:03:38 Rob Herring wrote: > > On Mon, Apr 11, 2016 at 01:11:46PM +0530, Nava kishore Manne wrote: > > > This patch updates the driver to support 64-bit DMA > > > addressing. > > > > > > Signed-off-by: Nava

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote: > > > On 2016/4/18 21:45, Jiri Olsa wrote: > >On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: > >>Use 'trigger' to model operations which need to be executed when > >>an event (a signal, for example) is observed. > >> >

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On Mon, Apr 18, 2016 at 10:20:23PM +0800, Wangnan (F) wrote: > > > On 2016/4/18 21:45, Jiri Olsa wrote: > >On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: > >>Use 'trigger' to model operations which need to be executed when > >>an event (a signal, for example) is observed. > >> >

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Mon, 18 Apr 2016, Ralf Baechle wrote: > The old case btw, affects ip22 with a random_config: > > CC arch/mips/mm/sc-ip22.o > {standard input}: Assembler messages: > {standard input}:137: Error: number (0x90008000) larger than 32 bits > {standard input}:162: Error: number

Re: {standard input}:136: Error: number (0x9000000080000000) larger than 32 bits

On Mon, 18 Apr 2016, Ralf Baechle wrote: > The old case btw, affects ip22 with a random_config: > > CC arch/mips/mm/sc-ip22.o > {standard input}: Assembler messages: > {standard input}:137: Error: number (0x90008000) larger than 32 bits > {standard input}:162: Error: number

Re: [tip:perf/urgent] perf hists: Fix determination of a callchain node's childlessness

Hi, Perhaps the patch quoted below should also go into stable? It'd be nice to fix that regression for 4.4 and 4.5. It's been integrated into 4.6 (909890355). Regards, Andres On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote: > Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8

Re: [tip:perf/urgent] perf hists: Fix determination of a callchain node's childlessness

Hi, Perhaps the patch quoted below should also go into stable? It'd be nice to fix that regression for 4.4 and 4.5. It's been integrated into 4.6 (909890355). Regards, Andres On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote: > Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8

[PATCH] mips: pistachio: Determine SoC revision during boot

Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley Signed-off-by: Ionela Voinescu

[PATCH] mips: pistachio: Determine SoC revision during boot

Now that there are different revisions of the Pistachio SoC in circulation, add this information to the boot log to make it easier for users to determine which hardware they have. Signed-off-by: James Hartley Signed-off-by: Ionela Voinescu diff --git a/arch/mips/pistachio/init.c

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

Hi Boris, On 04/15/2016 04:46 PM, Borislav Petkov wrote: On Fri, Apr 15, 2016 at 10:27:54AM -0500, Thor Thayer wrote: I'll update this patch to only count errors. ... and also think about what that counting is going to bring. If it is only going to be there to show how many network errors

Re: [PATCH] Add EDAC peripheral init functions & Ethernet EDAC.

Hi Boris, On 04/15/2016 04:46 PM, Borislav Petkov wrote: On Fri, Apr 15, 2016 at 10:27:54AM -0500, Thor Thayer wrote: I'll update this patch to only count errors. ... and also think about what that counting is going to bring. If it is only going to be there to show how many network errors

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Monday 18 April 2016 09:12:41 Josh Poimboeuf wrote: > On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote: > > On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > > > > > I agree. So how should we work around the bug in this case? There have > > > been several suggestions: >

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Monday 18 April 2016 09:12:41 Josh Poimboeuf wrote: > On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote: > > On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > > > > > I agree. So how should we work around the bug in this case? There have > > > been several suggestions: >

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On 2016/4/18 21:45, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: Use 'trigger' to model operations which need to be executed when an event (a signal, for example) is observed. States and transits: OFF--(on)--> READY --(toggle)--> TOGGLED --(process)-->

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On 2016/4/18 21:45, Jiri Olsa wrote: On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: Use 'trigger' to model operations which need to be executed when an event (a signal, for example) is observed. States and transits: OFF--(on)--> READY --(toggle)--> TOGGLED --(process)-->

[PATCHv6 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

[PATCHv6 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

Re: [PATCH 2/2] EDAC, altera: avoid unused function warnings

On 04/16/2016 03:13 PM, Arnd Bergmann wrote: The recently added Arria10 OCRAM ECC support caused some new harmless warnings about unused functions when it is disabled: drivers/edac/altera_edac.c:1067:20: error: 'altr_edac_a10_ecc_irq' defined but not used [-Werror=unused-function]

Re: [PATCH 2/2] EDAC, altera: avoid unused function warnings

On 04/16/2016 03:13 PM, Arnd Bergmann wrote: The recently added Arria10 OCRAM ECC support caused some new harmless warnings about unused functions when it is disabled: drivers/edac/altera_edac.c:1067:20: error: 'altr_edac_a10_ecc_irq' defined but not used [-Werror=unused-function]

Re: [PATCH v3 2/2] i2c: tegra: proper handling of error cases

On Mon, Apr 18, 2016 at 06:45:55PM +0530, Shardar Shariff Md wrote: > To summarize the issue observed in error cases: > > SW Flow: For i2c message transfer, packet header and data payload is > posted and then required error/packet completion interrupts are enabled > later. > > HW flow: HW

Re: [PATCH v3 2/2] i2c: tegra: proper handling of error cases

On Mon, Apr 18, 2016 at 06:45:55PM +0530, Shardar Shariff Md wrote: > To summarize the issue observed in error cases: > > SW Flow: For i2c message transfer, packet header and data payload is > posted and then required error/packet completion interrupts are enabled > later. > > HW flow: HW

[PATCH 1/1] perf intel-pt: Fix segfault tracing transactions

From: Adrian Hunter Tracing a workload that uses transactions gave a seg fault as follows: perf record -e intel_pt// workload perf report Program received signal SIGSEGV, Segmentation fault. 0x0054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110)

[PATCH 1/1] perf intel-pt: Fix segfault tracing transactions

From: Adrian Hunter Tracing a workload that uses transactions gave a seg fault as follows: perf record -e intel_pt// workload perf report Program received signal SIGSEGV, Segmentation fault. 0x0054b58c in intel_pt_reset_last_branch_rb (ptq=0x1a36110) at

[GIT PULL 0/1] perf/urgent fix

/acme/linux.git tags/perf-urgent-for-mingo-20160418 for you to fetch changes up to 1342e0b7a6c1a060c593037fbac9f4b717f1cb3b: perf intel-pt: Fix segfault tracing transactions (2016-04-18 11:00:56 -0300) perf/urgent fix: - Fix

Re: (.init.text+0x270): multiple definition of `plat_irq_setup'

On Mon, Apr 18, 2016 at 06:44:06PM +0800, kbuild test robot wrote: > Hi Rich, > > FYI, the error/warning still remains. I can't find where I got any notification of it before. Thanks for bringing it to my attention now though. > tree:

[GIT PULL 0/1] perf/urgent fix

/acme/linux.git tags/perf-urgent-for-mingo-20160418 for you to fetch changes up to 1342e0b7a6c1a060c593037fbac9f4b717f1cb3b: perf intel-pt: Fix segfault tracing transactions (2016-04-18 11:00:56 -0300) perf/urgent fix: - Fix

Re: (.init.text+0x270): multiple definition of `plat_irq_setup'

On Mon, Apr 18, 2016 at 06:44:06PM +0800, kbuild test robot wrote: > Hi Rich, > > FYI, the error/warning still remains. I can't find where I got any notification of it before. Thanks for bringing it to my attention now though. > tree:

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > I agree. So how should we work around the bug in this case? There have > been several suggestions: > > - change wwn_to_u64() to __always_inline > > - change qla2x00_get_host_fabric_name() to skip the unnecessary call to >

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > I agree. So how should we work around the bug in this case? There have > been several suggestions: > > - change wwn_to_u64() to __always_inline > > - change qla2x00_get_host_fabric_name() to skip the unnecessary call to >

Re: [PATCH 1/2] EDAC, altera: remove useless casts

On 04/16/2016 03:13 PM, Arnd Bergmann wrote: The altera EDAC driver refers to its per-device data using a cast to '(void *)', which makes the pointer non-const, though both the source and destination are actually const. Removing the annotation makes the reference (almost) fit into a single

Re: [PATCH 1/2] EDAC, altera: remove useless casts

On 04/16/2016 03:13 PM, Arnd Bergmann wrote: The altera EDAC driver refers to its per-device data using a cast to '(void *)', which makes the pointer non-const, though both the source and destination are actually const. Removing the annotation makes the reference (almost) fit into a single

Re: [PATCH] regulator: core: remove lockdep assert from suspend_prepare

On 18/04/16 14:59, Mark Brown wrote: On Mon, Apr 18, 2016 at 02:49:53PM +0300, Tero Kristo wrote: suspend_prepare can be called during regulator init time also, where It can be? That seems unexpected... regulator_register() -> set_machine_constraints() -> suspend_prepare() Called if

Re: [PATCH] regulator: core: remove lockdep assert from suspend_prepare

On 18/04/16 14:59, Mark Brown wrote: On Mon, Apr 18, 2016 at 02:49:53PM +0300, Tero Kristo wrote: suspend_prepare can be called during regulator init time also, where It can be? That seems unexpected... regulator_register() -> set_machine_constraints() -> suspend_prepare() Called if

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > > > I agree. So how should we work around the bug in this case? There have > > been several suggestions: > > > > - change wwn_to_u64() to __always_inline > > > > -

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, 2016-04-18 at 06:57 -0700, Guenter Roeck wrote: > On 04/18/2016 01:32 AM, Oliver Neukum wrote: > > On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: > >> This patch creates new driver that supports StreamLabs usb watchdog > >> device. This device plugs into 9-pin usb header and

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Mon, Apr 18, 2016 at 04:07:51PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 08:39:32 Josh Poimboeuf wrote: > > > > I agree. So how should we work around the bug in this case? There have > > been several suggestions: > > > > - change wwn_to_u64() to __always_inline > > > > -

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On Mon, 2016-04-18 at 06:57 -0700, Guenter Roeck wrote: > On 04/18/2016 01:32 AM, Oliver Neukum wrote: > > On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: > >> This patch creates new driver that supports StreamLabs usb watchdog > >> device. This device plugs into 9-pin usb header and

RE: [PATCH 0/2] Drivers: hv: balloon: two memory hotplug fixes

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Monday, April 18, 2016 5:59 AM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; Haiyang Zhang > ; Alex Ng (LIS) ; Cathy > Avery

RE: [PATCH 0/2] Drivers: hv: balloon: two memory hotplug fixes

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Monday, April 18, 2016 5:59 AM > To: KY Srinivasan > Cc: linux-kernel@vger.kernel.org; Haiyang Zhang > ; Alex Ng (LIS) ; Cathy > Avery ; de...@linuxdriverproject.org > Subject: Re: [PATCH 0/2] Drivers:

Re: [PATCH v6 01/12] usb: hcd: Initialize hcd->flags to 0

On Mon, 18 Apr 2016, Peter Chen wrote: > On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Quadros wrote: > > On 06/04/16 09:09, Felipe Balbi wrote: > > > > > > Hi, > > > > > > Roger Quadros writes: > > >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > > >> index

Re: [PATCH v6 01/12] usb: hcd: Initialize hcd->flags to 0

On Mon, 18 Apr 2016, Peter Chen wrote: > On Wed, Apr 06, 2016 at 09:32:22AM +0300, Roger Quadros wrote: > > On 06/04/16 09:09, Felipe Balbi wrote: > > > > > > Hi, > > > > > > Roger Quadros writes: > > >> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > > >> index 2ca2cef..6b1930d

Re: [PATCH v3 1/2] i2c: tegra: add separate function for config_load

On Mon, Apr 18, 2016 at 06:45:54PM +0530, Shardar Shariff Md wrote: > - Define separate function for configuration load register handling > to make it use by different functions later. > - Instead of calculating timeout for the config load during init, > calculate it when config load register is

Re: [PATCH v3 1/2] i2c: tegra: add separate function for config_load

On Mon, Apr 18, 2016 at 06:45:54PM +0530, Shardar Shariff Md wrote: > - Define separate function for configuration load register handling > to make it use by different functions later. > - Instead of calculating timeout for the config load during init, > calculate it when config load register is

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On Mon, 18 Apr 2016 16:48:26 +0300 Roger Quadros wrote: > Boris, > > On 18/04/16 16:13, Boris Brezillon wrote: > > Hi Roger, > > > > On Mon, 18 Apr 2016 15:52:58 +0300 > > Roger Quadros wrote: > > > >> On 18/04/16 15:31, Roger Quadros wrote: > >>> On 16/04/16

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

On Mon, 18 Apr 2016 16:48:26 +0300 Roger Quadros wrote: > Boris, > > On 18/04/16 16:13, Boris Brezillon wrote: > > Hi Roger, > > > > On Mon, 18 Apr 2016 15:52:58 +0300 > > Roger Quadros wrote: > > > >> On 18/04/16 15:31, Roger Quadros wrote: > >>> On 16/04/16 11:57, Boris Brezillon wrote: >

Re: [tip:perf/urgent] perf hists: Fix determination of a callchain node's childlessness

Em Sat, Apr 16, 2016 at 12:46:14PM -0700, Andres Freund escreveu: > Hi, > > Perhaps this should also go into stable? It'd be nice to fix that > regression for 4.4 and 4.5. Yeah, that would be good, just send that request to sta...@kernel.org. - Arnaldo > Regards, > > Andres > > On

Re: [tip:perf/urgent] perf hists: Fix determination of a callchain node's childlessness

Em Sat, Apr 16, 2016 at 12:46:14PM -0700, Andres Freund escreveu: > Hi, > > Perhaps this should also go into stable? It'd be nice to fix that > regression for 4.4 and 4.5. Yeah, that would be good, just send that request to sta...@kernel.org. - Arnaldo > Regards, > > Andres > > On

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > I'm not sure I understand the issue.  The public API is not about how > the driver works.  It doesn't say "don't use DMA API" anywhere, does it? > It's about telling device whether to obey the IOMMU and > about discovering whether a

Re: [PATCH RFC] fixup! virtio: convert to use DMA api

On Mon, 2016-04-18 at 16:12 +0300, Michael S. Tsirkin wrote: > I'm not sure I understand the issue.  The public API is not about how > the driver works.  It doesn't say "don't use DMA API" anywhere, does it? > It's about telling device whether to obey the IOMMU and > about discovering whether a

Re: [PATCHv5 2/3] x86/vdso: add mremap hook to vm_special_mapping

Hi Dmitry, [auto build test WARNING on v4.6-rc4] [also build test WARNING on next-20160418] [cannot apply to tip/x86/core tip/x86/vdso] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Dmitry

Re: [PATCHv5 2/3] x86/vdso: add mremap hook to vm_special_mapping

Hi Dmitry, [auto build test WARNING on v4.6-rc4] [also build test WARNING on next-20160418] [cannot apply to tip/x86/core tip/x86/vdso] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Dmitry

[PATCH v3 2/2] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[PATCH v3 2/2] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: > Use 'trigger' to model operations which need to be executed when > an event (a signal, for example) is observed. > > States and transits: > > OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING > ^

Re: [PATCH v4 1/6] perf tools: Derive trigger class from auxtrace_snapshot

On Mon, Apr 18, 2016 at 06:32:08AM +, Wang Nan wrote: > Use 'trigger' to model operations which need to be executed when > an event (a signal, for example) is observed. > > States and transits: > > OFF--(on)--> READY --(toggle)--> TOGGLED --(process)--> PROCESSING > ^

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Mon, Apr 18, 2016 at 09:49:10AM -0400, Sinan Kaya wrote: > Here is a good description of logical address vs. virtual address. > > https://www.quora.com/What-is-the-Kernel-logical-and-virtual-addresses-What-is-the-difference-between-them-What-is-the-type-of-addresses-listed-in-the-System-map

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On Mon, Apr 18, 2016 at 09:49:10AM -0400, Sinan Kaya wrote: > Here is a good description of logical address vs. virtual address. > > https://www.quora.com/What-is-the-Kernel-logical-and-virtual-addresses-What-is-the-difference-between-them-What-is-the-type-of-addresses-listed-in-the-System-map

Re: making a COW mapping on the fly from existing vma

On Sat, Apr 16, 2016 at 06:18:38AM +1000, Dave Airlie wrote: > This was just a random thought process I was having last night, and > wondered if it was possible. > > We have a scenario with OpenGL where certain APIs hand large amounts > of data from the user to the API and when you return from

Re: making a COW mapping on the fly from existing vma

On Sat, Apr 16, 2016 at 06:18:38AM +1000, Dave Airlie wrote: > This was just a random thought process I was having last night, and > wondered if it was possible. > > We have a scenario with OpenGL where certain APIs hand large amounts > of data from the user to the API and when you return from

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On 04/18/2016 01:32 AM, Oliver Neukum wrote: On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: This patch creates new driver that supports StreamLabs usb watchdog device. This device plugs into 9-pin usb header and connects to reset pin and reset button on common PC. USB commands used to

Re: [PATCH v2] watchdog: add driver for StreamLabs USB watchdog device

On 04/18/2016 01:32 AM, Oliver Neukum wrote: On Mon, 2016-04-18 at 03:53 +0100, Alexey Klimov wrote: This patch creates new driver that supports StreamLabs usb watchdog device. This device plugs into 9-pin usb header and connects to reset pin and reset button on common PC. USB commands used to

Re: [PATCHv2]brd: set max_discard_sectors properly

On Mon, Apr 18, 2016 at 10:34 AM, Jinpu Wang wrote: > On Sat, Apr 16, 2016 at 3:50 AM, Christoph Hellwig wrote: >>> - blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); >>> + blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX >>

Re: [PATCHv2]brd: set max_discard_sectors properly

On Mon, Apr 18, 2016 at 10:34 AM, Jinpu Wang wrote: > On Sat, Apr 16, 2016 at 3:50 AM, Christoph Hellwig wrote: >>> - blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); >>> + blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX >> 9); >> >> Shouldn't we fix the issue by capping

[PATCH v2 0/1] drivers: net: cpsw: Fix NULL pointer dereference with two slave PHYs

This is a fix for a NULL pointer dereference from cpsw which is triggered by having two slave PHYs attached to a cpsw network device. The problem is due to only maintaining a single reference to a PHY node in the prive data which gets overwritten by the second PHY probe. So move the PHY node

[PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs

Adding a 2nd PHY to cpsw results in a NULL pointer dereference as below. Fix by maintaining a reference to each PHY node in slave struct instead of a single reference in the priv struct which was overwritten by the 2nd PHY. [ 17.870933] Unable to handle kernel NULL pointer dereference at

[PATCH v2 0/1] drivers: net: cpsw: Fix NULL pointer dereference with two slave PHYs

This is a fix for a NULL pointer dereference from cpsw which is triggered by having two slave PHYs attached to a cpsw network device. The problem is due to only maintaining a single reference to a PHY node in the prive data which gets overwritten by the second PHY probe. So move the PHY node

[PATCH v2 1/1] drivers: net: cpsw: Prevent NUll pointer dereference with two PHYs

Adding a 2nd PHY to cpsw results in a NULL pointer dereference as below. Fix by maintaining a reference to each PHY node in slave struct instead of a single reference in the priv struct which was overwritten by the 2nd PHY. [ 17.870933] Unable to handle kernel NULL pointer dereference at

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 2:54 AM, Eli Cohen wrote: > Sinan, > > if we get rid of the part this code: > > if (BITS_PER_LONG == 64) { > struct page **pages; > pages = kmalloc(sizeof *pages * buf->nbufs, gfp); > if (!pages)

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 2:54 AM, Eli Cohen wrote: > Sinan, > > if we get rid of the part this code: > > if (BITS_PER_LONG == 64) { > struct page **pages; > pages = kmalloc(sizeof *pages * buf->nbufs, gfp); > if (!pages)

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 9:10 AM, Christoph Hellwig wrote: > On Mon, Apr 18, 2016 at 09:06:18AM -0400, ok...@codeaurora.org wrote: >> On 2016-04-18 08:12, Christoph Hellwig wrote: >>> On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote: Current code is assuming that the address returned by

Re: [PATCH V2] net: ethernet: mellanox: correct page conversion

On 4/18/2016 9:10 AM, Christoph Hellwig wrote: > On Mon, Apr 18, 2016 at 09:06:18AM -0400, ok...@codeaurora.org wrote: >> On 2016-04-18 08:12, Christoph Hellwig wrote: >>> On Sat, Apr 16, 2016 at 06:23:32PM -0400, Sinan Kaya wrote: Current code is assuming that the address returned by

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

Boris, On 18/04/16 16:13, Boris Brezillon wrote: > Hi Roger, > > On Mon, 18 Apr 2016 15:52:58 +0300 > Roger Quadros wrote: > >> On 18/04/16 15:31, Roger Quadros wrote: >>> On 16/04/16 11:57, Boris Brezillon wrote: On Fri, 15 Apr 2016 09:19:51 -0700 Tony Lindgren

Re: [PATCH v6 00/17] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

Boris, On 18/04/16 16:13, Boris Brezillon wrote: > Hi Roger, > > On Mon, 18 Apr 2016 15:52:58 +0300 > Roger Quadros wrote: > >> On 18/04/16 15:31, Roger Quadros wrote: >>> On 16/04/16 11:57, Boris Brezillon wrote: On Fri, 15 Apr 2016 09:19:51 -0700 Tony Lindgren wrote: >

Re: [PATCH for-next] spi: bcm53xx: add spi_flash_read callback for MMIO-based reads

On 04/18/2016 05:08 PM, Rafał Miłecki wrote: > On 18 April 2016 at 13:24, Mark Brown wrote: >> On Mon, Apr 18, 2016 at 01:10:43PM +0200, Rafał Miłecki wrote: >> >>> +static int bcm53xxspi_flash_read(struct spi_device *spi, >>> + struct

Re: [PATCH for-next] spi: bcm53xx: add spi_flash_read callback for MMIO-based reads

On 04/18/2016 05:08 PM, Rafał Miłecki wrote: > On 18 April 2016 at 13:24, Mark Brown wrote: >> On Mon, Apr 18, 2016 at 01:10:43PM +0200, Rafał Miłecki wrote: >> >>> +static int bcm53xxspi_flash_read(struct spi_device *spi, >>> + struct spi_flash_read_message *msg)

Re: [BUG] machine check Oops on Alpha

On Mon, 18 Apr 2016, Bob Tracy wrote: > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure > patched by Daniel Wagner back in February (incompatible-pointer-types > warning treated as error by compiler). Is Daniel's patch queued for > incorporation into the main kernel source

Re: [BUG] machine check Oops on Alpha

On Mon, 18 Apr 2016, Bob Tracy wrote: > Build delayed slightly. Ran into "fs/binfmt_em86.o" build failure > patched by Daniel Wagner back in February (incompatible-pointer-types > warning treated as error by compiler). Is Daniel's patch queued for > incorporation into the main kernel source

Re: [PATCH] kprobes: add the "tls" argument for j_do_fork

On Thu 2016-04-14 17:16:40, Huang Shijie wrote: > The patch "3033f14a clone: support passing tls argument via C rather ..." > added the tls argument for _do_fork(). The patch adds the "tls" argument > for j_do_fork to make it match _do_fork(). > > Acked-by: Steve Capper >

Re: [PATCH] kprobes: add the "tls" argument for j_do_fork

On Thu 2016-04-14 17:16:40, Huang Shijie wrote: > The patch "3033f14a clone: support passing tls argument via C rather ..." > added the tls argument for _do_fork(). The patch adds the "tls" argument > for j_do_fork to make it match _do_fork(). > > Acked-by: Steve Capper > Cc: Masami Hiramatsu

[PATCHv5 3/3] selftest/x86: add mremap vdso 32-bit test

Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f774] -> [a00, a001000] [OK] Or segfault if landing was bad (before patches): [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is

[PATCHv5 3/3] selftest/x86: add mremap vdso 32-bit test

Should print on success: [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is 0xf773f000 [NOTE] Moving vDSO: [f773f000, f774] -> [a00, a001000] [OK] Or segfault if landing was bad (before patches): [root@localhost ~]# ./test_mremap_vdso_32 AT_SYSINFO_EHDR is

[PATCHv5 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

[PATCHv5 1/3] x86: rename is_{ia32,x32}_task to in_{ia32,x32}_syscall

Impact: clearify meaning Suggested-by: Andy Lutomirski Suggested-by: Ingo Molnar Signed-off-by: Dmitry Safonov Acked-by: Andy Lutomirski --- v3: initial patch arch/x86/entry/common.c| 2 +-

[PATCHv5 1/3] x86: rename is_{ia32,x32}_task to in_{ia32,x32}_syscall

Impact: clearify meaning Suggested-by: Andy Lutomirski Suggested-by: Ingo Molnar Signed-off-by: Dmitry Safonov Acked-by: Andy Lutomirski --- v3: initial patch arch/x86/entry/common.c| 2 +- arch/x86/include/asm/compat.h | 4 ++-- arch/x86/include/asm/thread_info.h | 2 +-

[PATCHv5 2/3] x86/vdso: add mremap hook to vm_special_mapping

Add possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. This

Re: [patch -next] udp: fix if statement in SIOCINQ ioctl

On Mon, Apr 18, 2016 at 8:19 AM, Eric Dumazet wrote: > On Mon, 2016-04-18 at 11:44 +0300, Dan Carpenter wrote: >> We deleted a line of code and accidentally made the "return put_user()" >> part of the if statement when it's supposed to be unconditional. >> >> Fixes:

Re: [patch -next] udp: fix if statement in SIOCINQ ioctl

On Mon, Apr 18, 2016 at 8:19 AM, Eric Dumazet wrote: > On Mon, 2016-04-18 at 11:44 +0300, Dan Carpenter wrote: >> We deleted a line of code and accidentally made the "return put_user()" >> part of the if statement when it's supposed to be unconditional. >> >> Fixes: 9f9a45beaa96 ('udp: do not

Re: [PATCH 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

On 15/04/16 15:12, Will Deacon wrote: On Fri, Apr 15, 2016 at 03:10:27PM +0100, Suzuki K Poulose wrote: On 14/04/16 18:49, Suzuki K Poulose wrote: On 14/04/16 18:39, Will Deacon wrote: On Wed, Apr 06, 2016 at 12:24:13PM +0100, Suzuki K Poulose wrote: CPU Errata work arounds are detected and

Re: [PATCH 4/5] arm64: Verify CPU errata work arounds on hotplugged CPU

On 15/04/16 15:12, Will Deacon wrote: On Fri, Apr 15, 2016 at 03:10:27PM +0100, Suzuki K Poulose wrote: On 14/04/16 18:49, Suzuki K Poulose wrote: On 14/04/16 18:39, Will Deacon wrote: On Wed, Apr 06, 2016 at 12:24:13PM +0100, Suzuki K Poulose wrote: CPU Errata work arounds are detected and

[PATCH v2] ASoC: docs: add clocking examples for DAI formats

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin --- Documentation/sound/alsa/soc/clocking.txt | 145

[PATCH v2] ASoC: docs: add clocking examples for DAI formats

Provide *our* view of what the rules are for the different DAI formats, so that we do not have to trust external interpretations for this crucial bit of interoperability. Signed-off-by: Peter Rosin --- Documentation/sound/alsa/soc/clocking.txt | 145 +- 1 file

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Sat, Apr 16, 2016 at 11:03:32AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > > I don't think we know yet if there's a reliable way to turn the bug off. > > > > > > Also, according to the gcc guys, this bug won't always result in a > > > truncated

Re: This patch triggers a bad gcc bug (was Re: [PATCH] force inlining of some byteswap operations)

On Sat, Apr 16, 2016 at 11:03:32AM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > > I don't think we know yet if there's a reliable way to turn the bug off. > > > > > > Also, according to the gcc guys, this bug won't always result in a > > > truncated function, and may sometimes

get_nohz_timer_target?

Looking at kernel/sched/core.c:get_nohz_timer_target(), I don't understand the change made in: commit 9642d18eee2cd169b60c6ac0f20bda745b5a3d1e Author: Vatika Harlalka Date: Tue Sep 1 16:50:59 2015 +0200 nohz: Affine unpinned timers to housekeepers

Re: [PATCH 3/3] sched: Optimize !CONFIG_NO_HZ_COMMON cpu load updates

On Wed, Apr 13, 2016 at 03:56:52PM +0200, Frederic Weisbecker wrote: > Some code in cpu load update only concern NO_HZ configs but it is > built on all configurations. When NO_HZ isn't built, that code is harmless > but just happens to take some useless ressources in CPU and memory: > > 1) one

<    5   6   7   8   9   10   11   12   13   14   >