[PATCH] MIPS:wrong usage of l_exc_copy in octeon-memcpy.S

l_exc_copy() is usually to be used like this: 1 EXC( LOADt0, UNIT(0)(src), l_exc) 2 EXC( LOADt1, UNIT(1)(src), l_exc_copy) 3 EXC( LOADt2, UNIT(2)(src), l_exc_copy) 4 EXC( LOADt3, UNIT(3)(src), l_exc_copy) When the fault occurs on row 4, l_exc_copy will

[PATCH] MIPS:wrong usage of l_exc_copy in octeon-memcpy.S

l_exc_copy() is usually to be used like this: 1 EXC( LOADt0, UNIT(0)(src), l_exc) 2 EXC( LOADt1, UNIT(1)(src), l_exc_copy) 3 EXC( LOADt2, UNIT(2)(src), l_exc_copy) 4 EXC( LOADt3, UNIT(3)(src), l_exc_copy) When the fault occurs on row 4, l_exc_copy will

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On 2017年02月19日 13:08, Michael S. Tsirkin wrote: - oxdp_qp = vi->xdp_queue_pairs; - /* Changing the headroom in buffers is a disruptive operation because * existing buffers must be flushed and reallocated. This will happen * when a xdp program is initially added

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On 2017年02月19日 13:08, Michael S. Tsirkin wrote: - oxdp_qp = vi->xdp_queue_pairs; - /* Changing the headroom in buffers is a disruptive operation because * existing buffers must be flushed and reallocated. This will happen * when a xdp program is initially added

[GIT PULL] hwmon updates for v4.11

Hi Linus, Please pull hwmon updates for Linux v4.11 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.11 Thanks, Guenter -- The following changes since commit e9572fdd13e299cfba03abbfd2786c84ac055249: hwmon: (lm90) fix

[GIT PULL] hwmon updates for v4.11

Hi Linus, Please pull hwmon updates for Linux v4.11 from signed tag: git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git hwmon-for-linus-v4.11 Thanks, Guenter -- The following changes since commit e9572fdd13e299cfba03abbfd2786c84ac055249: hwmon: (lm90) fix

Re: [PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.

On February 19, 2017 6:00 PM Aneesh Kumar K.V wrote: > > We are using wrong flag value in task_numa_falt function. This can result in > us doing wrong numa fault statistics update, because we update > num_pages_migrate > and numa_fault_locality etc based on the flag argument passed. > >

Re: [PATCH] mm/thp/autonuma: Use TNF flag instead of vm fault.

On February 19, 2017 6:00 PM Aneesh Kumar K.V wrote: > > We are using wrong flag value in task_numa_falt function. This can result in > us doing wrong numa fault statistics update, because we update > num_pages_migrate > and numa_fault_locality etc based on the flag argument passed. > >

Re: [PATCH v2] MAINTAINERS: cpufreq: add bmips-cpufreq.c

On 17-02-17, 12:27, Markus Mayer wrote: > From: Markus Mayer > > Add maintainer information for bmips-cpufreq.c. > > Signed-off-by: Markus Mayer > Acked-by: Florian Fainelli > --- > > This is based on PM's linux-next from today

Re: [PATCH v2] MAINTAINERS: cpufreq: add bmips-cpufreq.c

On 17-02-17, 12:27, Markus Mayer wrote: > From: Markus Mayer > > Add maintainer information for bmips-cpufreq.c. > > Signed-off-by: Markus Mayer > Acked-by: Florian Fainelli > --- > > This is based on PM's linux-next from today (February 17). > > This patch could be squashed into patch 3/4

[PATCH v4 05/10] powerpc/perf: Generic imc pmu event functions

Since, the IMC counters' data are periodically fed to a memory location, the functions to read/update, start/stop, add/del can be generic and can be used by all IMC PMU units. This patch adds a set of generic imc pmu related event functions to be used by each imc pmu unit. Add code to setup

[PATCH v4 05/10] powerpc/perf: Generic imc pmu event functions

Since, the IMC counters' data are periodically fed to a memory location, the functions to read/update, start/stop, add/del can be generic and can be used by all IMC PMU units. This patch adds a set of generic imc pmu related event functions to be used by each imc pmu unit. Add code to setup

[PATCH v4 04/10] powerpc/perf: Add event attribute and group to IMC pmus

Device tree IMC driver code parses the IMC units and their events. It passes the information to IMC pmu code which is placed in powerpc/perf as "imc-pmu.c". This patch creates only event attributes and attribute groups for the IMC pmus. Cc: Madhavan Srinivasan Cc:

[PATCH v4 06/10] powerpc/perf: IMC pmu cpumask and cpu hotplug support

Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any online CPU) from each chip for nest PMUs is designated to read counters. On CPU hotplug, dying CPU is checked to see whether it is one of the designated cpus, if yes, next online cpu from the same chip (for nest units) is

[PATCH v4 07/10] powerpc/powernv: Core IMC events detection

This patch adds support for detection of core IMC events along with the Nest IMC events. It adds a new domain IMC_DOMAIN_CORE and its determined with the help of the compatibility string "ibm,imc-counters-core" based on the IMC device tree. Cc: Madhavan Srinivasan Cc:

[PATCH v4 04/10] powerpc/perf: Add event attribute and group to IMC pmus

Device tree IMC driver code parses the IMC units and their events. It passes the information to IMC pmu code which is placed in powerpc/perf as "imc-pmu.c". This patch creates only event attributes and attribute groups for the IMC pmus. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Benjamin

[PATCH v4 06/10] powerpc/perf: IMC pmu cpumask and cpu hotplug support

Adds cpumask attribute to be used by each IMC pmu. Only one cpu (any online CPU) from each chip for nest PMUs is designated to read counters. On CPU hotplug, dying CPU is checked to see whether it is one of the designated cpus, if yes, next online cpu from the same chip (for nest units) is

[PATCH v4 07/10] powerpc/powernv: Core IMC events detection

This patch adds support for detection of core IMC events along with the Nest IMC events. It adds a new domain IMC_DOMAIN_CORE and its determined with the help of the compatibility string "ibm,imc-counters-core" based on the IMC device tree. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc:

[PATCH v4 01/10] powerpc/powernv: Data structure and macros definitions

Create new header file "imc-pmu.h" to add the data structures and macros needed for IMC pmu support. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Anton

[PATCH v4 02/10] powerpc/powernv: Autoload IMC device driver module

This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory region details from the system device tree and get the base address of HOMER region address for each chip. - We

[PATCH v4 01/10] powerpc/powernv: Data structure and macros definitions

Create new header file "imc-pmu.h" to add the data structures and macros needed for IMC pmu support. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Anton Blanchard Cc: Sukadev Bhattiprolu Cc: Michael Neuling Cc: Stewart Smith Cc: Daniel

[PATCH v4 02/10] powerpc/powernv: Autoload IMC device driver module

This patch does three things : - Enables "opal.c" to create a platform device for the IMC interface according to the appropriate compatibility string. - Find the reserved-memory region details from the system device tree and get the base address of HOMER region address for each chip. - We

[PATCH v4 03/10] powerpc/powernv: Detect supported IMC units and its events

Parse device tree to detect IMC units. Traverse through each IMC unit node to find supported events and corresponding unit/scale files (if any). The device tree for IMC counters starts at the node : "imc-counters". This node contains all the IMC PMU nodes and event nodes for these IMC PMUs. The

[PATCH v4 10/10] powerpc/perf: Thread IMC PMU functions

This patch adds the PMU functions required for event initialization, read, update, add, del etc. for thread IMC PMU. Thread IMC PMUs are used for per-task monitoring. These PMUs don't need any hotplugging support. For each CPU, a page of memory is allocated and is kept static i.e., these pages

[PATCH v4 03/10] powerpc/powernv: Detect supported IMC units and its events

Parse device tree to detect IMC units. Traverse through each IMC unit node to find supported events and corresponding unit/scale files (if any). The device tree for IMC counters starts at the node : "imc-counters". This node contains all the IMC PMU nodes and event nodes for these IMC PMUs. The

[PATCH v4 10/10] powerpc/perf: Thread IMC PMU functions

This patch adds the PMU functions required for event initialization, read, update, add, del etc. for thread IMC PMU. Thread IMC PMUs are used for per-task monitoring. These PMUs don't need any hotplugging support. For each CPU, a page of memory is allocated and is kept static i.e., these pages

[PATCH v4 09/10] powerpc/powernv: Thread IMC events detection

Patch adds support for detection of thread IMC events. It adds a new domain IMC_DOMAIN_THREAD and it is determined with the help of the compatibility string "ibm,imc-counters-thread" based on the IMC device tree. Cc: Madhavan Srinivasan Cc: Michael Ellerman

[PATCH v4 09/10] powerpc/powernv: Thread IMC events detection

Patch adds support for detection of thread IMC events. It adds a new domain IMC_DOMAIN_THREAD and it is determined with the help of the compatibility string "ibm,imc-counters-thread" based on the IMC device tree. Cc: Madhavan Srinivasan Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul

[PATCH v4 00/10] IMC Instrumentation Support

Power 9 has In-Memory-Collection (IMC) infrastructure which contains various Performance Monitoring Units (PMUs) at Nest level (these are on-chip but off-core), Core level and Thread level. The Nest PMU counters are handled by a Nest IMC microcode which runs in the OCC (On-Chip Controller)

[PATCH v4 00/10] IMC Instrumentation Support

Power 9 has In-Memory-Collection (IMC) infrastructure which contains various Performance Monitoring Units (PMUs) at Nest level (these are on-chip but off-core), Core level and Thread level. The Nest PMU counters are handled by a Nest IMC microcode which runs in the OCC (On-Chip Controller)

[PATCH v4 08/10] powerpc/perf: PMU functions for Core IMC and hotplugging

This patch adds the PMU function to initialize a core IMC event. It also adds cpumask initialization function for core IMC PMU. For initialization, a page of memory is allocated per core where the data for core IMC counters will be accumulated. The base address for this page is sent to OPAL via an

[PATCH v4 08/10] powerpc/perf: PMU functions for Core IMC and hotplugging

This patch adds the PMU function to initialize a core IMC event. It also adds cpumask initialization function for core IMC PMU. For initialization, a page of memory is allocated per core where the data for core IMC counters will be accumulated. The base address for this page is sent to OPAL via an

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

Hi Borislav, On Sun, Feb 19, 2017 at 02:50:19PM +0100, Borislav Petkov wrote: On Sun, Feb 19, 2017 at 09:06:51AM +0800, Fengguang Wu wrote: Yes if we add it as a line below the branch URL, it could be a time saver. Right. Since it's hard to teach ALL people about the rule, it'd be best if

Re: [clear_page] 0ad07c8104 BUG: unable to handle kernel NULL pointer dereference at 0000000000000040

Hi Borislav, On Sun, Feb 19, 2017 at 02:50:19PM +0100, Borislav Petkov wrote: On Sun, Feb 19, 2017 at 09:06:51AM +0800, Fengguang Wu wrote: Yes if we add it as a line below the branch URL, it could be a time saver. Right. Since it's hard to teach ALL people about the rule, it'd be best if

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 07:59 PM, Jens Axboe wrote: > On 02/19/2017 07:12 PM, James Bottomley wrote: >> On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >>> On 02/19/2017 06:09 PM, Bart Van Assche wrote: On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 07:59 PM, Jens Axboe wrote: > On 02/19/2017 07:12 PM, James Bottomley wrote: >> On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >>> On 02/19/2017 06:09 PM, Bart Van Assche wrote: On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 07:12 PM, James Bottomley wrote: > On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >> On 02/19/2017 06:09 PM, Bart Van Assche wrote: >>> On 02/19/2017 04:11 PM, Jens Axboe wrote: - Removal of the BLOCK_PC support in struct request, and refactoring of carrying

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 07:12 PM, James Bottomley wrote: > On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: >> On 02/19/2017 06:09 PM, Bart Van Assche wrote: >>> On 02/19/2017 04:11 PM, Jens Axboe wrote: - Removal of the BLOCK_PC support in struct request, and refactoring of carrying

linux-next: manual merge of the target-bva tree with the target-updates tree

Hi Bart, Today's linux-next merge of the target-bva tree got conflicts in: drivers/target/iscsi/cxgbit/cxgbit_target.c drivers/target/iscsi/iscsi_target.c include/target/iscsi/iscsi_transport.h between commits: 9a584bf9bf0a ("target/iscsi: split iscsit_check_dataout_hdr()")

linux-next: manual merge of the target-bva tree with the target-updates tree

Hi Bart, Today's linux-next merge of the target-bva tree got conflicts in: drivers/target/iscsi/cxgbit/cxgbit_target.c drivers/target/iscsi/iscsi_target.c include/target/iscsi/iscsi_transport.h between commits: 9a584bf9bf0a ("target/iscsi: split iscsit_check_dataout_hdr()")

Re: [PATCH RESEND v7 1/1] usb: xhci: plat: Enable async suspend/resume

On 10 February 2017 at 22:56, Robert Foss wrote: > From: Andrew Bresticker > > USB host controllers can take a significant amount of time to suspend > and resume, adding several hundred miliseconds to the kernel resume > time. Since the XHCI

Re: [PATCH RESEND v7 1/1] usb: xhci: plat: Enable async suspend/resume

On 10 February 2017 at 22:56, Robert Foss wrote: > From: Andrew Bresticker > > USB host controllers can take a significant amount of time to suspend > and resume, adding several hundred miliseconds to the kernel resume > time. Since the XHCI controller has no outside dependencies (other than >

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi Mathias, On 6 February 2017 at 13:26, Baolin Wang wrote: > Hi Mathias, > > On 31 January 2017 at 21:14, Mathias Nyman > wrote: >> On 16.01.2017 12:56, Baolin Wang wrote: >>> >>> Hi Mathias, >> >> >> Hi >> >> Sorry about the long review

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

Hi Mathias, On 6 February 2017 at 13:26, Baolin Wang wrote: > Hi Mathias, > > On 31 January 2017 at 21:14, Mathias Nyman > wrote: >> On 16.01.2017 12:56, Baolin Wang wrote: >>> >>> Hi Mathias, >> >> >> Hi >> >> Sorry about the long review delay >> CC Alan in case my pm assumptions need to be

Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction

Hi Zain, On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: > > The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. > But sometimes we will send a bare address packet to start the transaction, > like drm_dp_i2c_xfer() show: > .. > /*

Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction

Hi Zain, On Mon, Feb 13, 2017 at 6:27 PM, zain wang wrote: > > The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. > But sometimes we will send a bare address packet to start the transaction, > like drm_dp_i2c_xfer() show: > .. > /* Send a bare address

Re: [PATCH] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()

> In Linux kernel 4.9-rc1, the function ib_get_dma_mr() > was removed and a second parameter was added to ib_alloc_pd(). > As this broke the building of the ko2iblnd module in > staging, the Kconfig for LNet has marked ko2iblnd as broken > and stopped building it. > > This patch fixes this

Re: [PATCH] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()

> In Linux kernel 4.9-rc1, the function ib_get_dma_mr() > was removed and a second parameter was added to ib_alloc_pd(). > As this broke the building of the ko2iblnd module in > staging, the Kconfig for LNet has marked ko2iblnd as broken > and stopped building it. > > This patch fixes this

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

On 17 February 2017 at 16:04, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: (One possible approach would be to have the setup routine return different values for explicit and implicit status stages -- for example, return 1 if it

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

On 17 February 2017 at 16:04, Felipe Balbi wrote: > > Hi, > > Baolin Wang writes: (One possible approach would be to have the setup routine return different values for explicit and implicit status stages -- for example, return 1 if it wants to submit an explicit status request.

Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction

Hi Sean, Could you give some comments for this patch? Thanks Zain 在 2017/2/13 17:27, zain wang 写道: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show:

Re: [PATCH] drm/bridge: analogix_dp: Don't return -EBUSY when msg->size is 0 in aux transaction

Hi Sean, Could you give some comments for this patch? Thanks Zain 在 2017/2/13 17:27, zain wang 写道: The analogix_dp_transfer() will return -EBUSY if num_transferred is zero. But sometimes we will send a bare address packet to start the transaction, like drm_dp_i2c_xfer() show:

Re: [GIT PULL] Block pull request for- 4.11-rc1

On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: > On 02/19/2017 06:09 PM, Bart Van Assche wrote: > > On 02/19/2017 04:11 PM, Jens Axboe wrote: > > > - Removal of the BLOCK_PC support in struct request, and > > > refactoring of > > > carrying SCSI payloads in the block layer. This cleans up

Re: [GIT PULL] Block pull request for- 4.11-rc1

On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: > On 02/19/2017 06:09 PM, Bart Van Assche wrote: > > On 02/19/2017 04:11 PM, Jens Axboe wrote: > > > - Removal of the BLOCK_PC support in struct request, and > > > refactoring of > > > carrying SCSI payloads in the block layer. This cleans up

[PATCH] PM / AVS: rockchip-io: add io selectors and supplies for rk3328

From: "david.wu" This adds the necessary data for handling io voltage domains on the rk3328. As interesting tidbit, the rk3328 only contains one iodomain area in the regular General Register Files (GRF). Signed-off-by: david.wu ---

[PATCH] PM / AVS: rockchip-io: add io selectors and supplies for rk3328

From: "david.wu" This adds the necessary data for handling io voltage domains on the rk3328. As interesting tidbit, the rk3328 only contains one iodomain area in the regular General Register Files (GRF). Signed-off-by: david.wu --- .../bindings/power/rockchip-io-domain.txt | 1 +

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 2017-02-19 17:33, Bryan O'Donoghue wrote: > > > On 19/02/17 13:33, Jan Kiszka wrote: >>> I would not object strongly to having conditionally compiled code in >>> mainline that adds support for this, but bodging the default code path >>> like this for a Quark quirk is out of the question imo.

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 2017-02-19 17:33, Bryan O'Donoghue wrote: > > > On 19/02/17 13:33, Jan Kiszka wrote: >>> I would not object strongly to having conditionally compiled code in >>> mainline that adds support for this, but bodging the default code path >>> like this for a Quark quirk is out of the question imo.

[GIT pull] irq updates for 4.11

Linus, please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus This update provides: - Yet another two irq controller chip drivers - A few updates and fixes for GICV3 - A resource managed function for

[PATCH v2 1/1] gpio: altera: Use handle_level_irq when configured as a level_high

When a threaded irq handler is chained attached to one of the gpio pins when configure for level irq the altera_gpio_irq_leveL_high_handler does not mask the interrupt while being handled by the chained irq. This resulting in the threaded irq not getting enough cycles to complete quickly enough

[GIT pull] irq updates for 4.11

Linus, please pull the latest irq-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-for-linus This update provides: - Yet another two irq controller chip drivers - A few updates and fixes for GICV3 - A resource managed function for

[PATCH v2 1/1] gpio: altera: Use handle_level_irq when configured as a level_high

When a threaded irq handler is chained attached to one of the gpio pins when configure for level irq the altera_gpio_irq_leveL_high_handler does not mask the interrupt while being handled by the chained irq. This resulting in the threaded irq not getting enough cycles to complete quickly enough

Re: [PATCH] drm/rockchip: cdn-dp: Fix error handling

On 2017年02月20日 00:59, Christophe JAILLET wrote: It is likely that both 'clk_disable_unprepare()' should be called if 'pm_runtime_get_sync()' fails. Add a new label for that, because 'err_set_rate' is not meaningful in this case. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support

Re: [PATCH] drm/rockchip: cdn-dp: Fix error handling

On 2017年02月20日 00:59, Christophe JAILLET wrote: It is likely that both 'clk_disable_unprepare()' should be called if 'pm_runtime_get_sync()' fails. Add a new label for that, because 'err_set_rate' is not meaningful in this case. Fixes: 1a0f7ed3abe2 ("drm/rockchip: cdn-dp: add cdn DP support

[GIT pull} timer updates for 4.11

Linus, please pull the latest timers-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-core-for-linus Nothing exciting, just the usual pile of fixes, updates and cleanups: - A bunch of clocksource driver updates - Removal of

[GIT pull} timer updates for 4.11

Linus, please pull the latest timers-core-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers-core-for-linus Nothing exciting, just the usual pile of fixes, updates and cleanups: - A bunch of clocksource driver updates - Removal of

[tip:WIP.sched/core 102/154] include/linux/list.h:463:43: error: dereferencing pointer to incomplete type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 12372f63e2728a509817b56878cd6633d92053b3 commit: 39a8751a41237a0f039083161faddb8bf48e4e70 [102/154] sched/headers: Remove the dependency from config: xtensa-allmodconfig (attached as .config) compiler:

[tip:WIP.sched/core 102/154] include/linux/list.h:463:43: error: dereferencing pointer to incomplete type

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.sched/core head: 12372f63e2728a509817b56878cd6633d92053b3 commit: 39a8751a41237a0f039083161faddb8bf48e4e70 [102/154] sched/headers: Remove the dependency from config: xtensa-allmodconfig (attached as .config) compiler:

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 19/02/17 13:33, Jan Kiszka wrote: I would not object strongly to having conditionally compiled code in mainline that adds support for this, but bodging the default code path like this for a Quark quirk is out of the question imo. I'm open for any consensus that avoids bending mainline too

Re: [PATCH 0/2] efi: Enhance capsule loader to support signed Quark images

On 19/02/17 13:33, Jan Kiszka wrote: I would not object strongly to having conditionally compiled code in mainline that adds support for this, but bodging the default code path like this for a Quark quirk is out of the question imo. I'm open for any consensus that avoids bending mainline too

linux-next: manual merge of the tip tree with the net-next tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/extable.c between commit: 74451e66d516 ("bpf: make jited programs visible in traces") from the net-next tree and commit: 5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text area") from

linux-next: manual merge of the tip tree with the net-next tree

Hi all, Today's linux-next merge of the tip tree got a conflict in: kernel/extable.c between commit: 74451e66d516 ("bpf: make jited programs visible in traces") from the net-next tree and commit: 5b485629ba0d ("kprobes, extable: Identify kprobes trampolines as kernel text area") from

Re: [PATCH] Input: tsc2007 - switch to using input_set_capability()

On Sat, Feb 18, 2017 at 03:58:39PM +0100, H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Am 17.02.2017 um 23:56 schrieb Dmitry Torokhov : > > > > Do not manipulate evbit/keybit directly, use helper for that. > > > > Signed-off-by: Dmitry Torokhov

Re: [PATCH] Input: tsc2007 - switch to using input_set_capability()

On Sat, Feb 18, 2017 at 03:58:39PM +0100, H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Am 17.02.2017 um 23:56 schrieb Dmitry Torokhov : > > > > Do not manipulate evbit/keybit directly, use helper for that. > > > > Signed-off-by: Dmitry Torokhov > > --- > >

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 06:09 PM, Bart Van Assche wrote: > On 02/19/2017 04:11 PM, Jens Axboe wrote: >> - Removal of the BLOCK_PC support in struct request, and refactoring of >> carrying SCSI payloads in the block layer. This cleans up the code >> nicely, and enables us to kill the SCSI specific parts

Re: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 06:09 PM, Bart Van Assche wrote: > On 02/19/2017 04:11 PM, Jens Axboe wrote: >> - Removal of the BLOCK_PC support in struct request, and refactoring of >> carrying SCSI payloads in the block layer. This cleans up the code >> nicely, and enables us to kill the SCSI specific parts

[PATCH -v2] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area

From: Huang Ying It was reported that on some machines, there is overlap between ACPI NVS area and BERT address range. This appears reasonable because BERT contents need to be non-volatile across reboot. But this will cause resources conflict in current Linux kernel

[PATCH -v2] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area

From: Huang Ying It was reported that on some machines, there is overlap between ACPI NVS area and BERT address range. This appears reasonable because BERT contents need to be non-volatile across reboot. But this will cause resources conflict in current Linux kernel implementation because the

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Nikolaus, On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov : > > > > Hi Nikolaus, > > > > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote: > >> Hi Dmitry, >

Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding names, pre-calibration, flipping and rotation

Hi Nikolaus, On Sat, Feb 18, 2017 at 12:32:48PM +0100, H. Nikolaus Schaller wrote: > Hi Dmitry, > > > Am 17.02.2017 um 21:40 schrieb Dmitry Torokhov : > > > > Hi Nikolaus, > > > > On Sat, Jan 28, 2017 at 10:44:35PM +0100, H. Nikolaus Schaller wrote: > >> Hi Dmitry, > >> > >>> Am 28.01.2017 um

RE: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct request, and refactoring of > carrying SCSI payloads in the block layer. This cleans up the code > nicely, and enables us to kill the SCSI specific parts of struct > request, shrinking it down nicely.

RE: [GIT PULL] Block pull request for- 4.11-rc1

On 02/19/2017 04:11 PM, Jens Axboe wrote: > - Removal of the BLOCK_PC support in struct request, and refactoring of > carrying SCSI payloads in the block layer. This cleans up the code > nicely, and enables us to kill the SCSI specific parts of struct > request, shrinking it down nicely.

Re: [RFC 01/13] Core changes for CCP2/CSI1 support.

Hi Pavel, As a general note, when posting a patch series, please include a cover letter and send all patches as replies to the cover letter. It gets very difficult to associate them together if you send them separately. -- Regards, Laurent Pinchart

Re: [RFC 01/13] Core changes for CCP2/CSI1 support.

Hi Pavel, As a general note, when posting a patch series, please include a cover letter and send all patches as replies to the cover letter. It gets very difficult to associate them together if you send them separately. -- Regards, Laurent Pinchart

Re: [PATCH] omap3isp: add support for CSI1 bus

Hi Pavel, On Wednesday 15 Feb 2017 10:42:29 Pavel Machek wrote: > Hi! > > >> diff --git a/drivers/media/platform/omap3isp/isp.c > >> b/drivers/media/platform/omap3isp/isp.c index 0321d84..88bc7c6 100644 > >> --- a/drivers/media/platform/omap3isp/isp.c > >> +++

Re: [PATCH] omap3isp: add support for CSI1 bus

Hi Pavel, On Wednesday 15 Feb 2017 10:42:29 Pavel Machek wrote: > Hi! > > >> diff --git a/drivers/media/platform/omap3isp/isp.c > >> b/drivers/media/platform/omap3isp/isp.c index 0321d84..88bc7c6 100644 > >> --- a/drivers/media/platform/omap3isp/isp.c > >> +++

Re: [PATCH] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area

Borislav Petkov writes: > On Fri, Feb 17, 2017 at 08:31:12AM +0800, Huang, Ying wrote: >> I am not sure whether the NVS area is a part of the BERT area, but >> apparently they are overlapped in some way. We will access the whole >> BERT area here via ioremap the whole range. > >

Re: [PATCH] ACPI, APEI: Fix BERT resources conflict with ACPI NVS area

Borislav Petkov writes: > On Fri, Feb 17, 2017 at 08:31:12AM +0800, Huang, Ying wrote: >> I am not sure whether the NVS area is a part of the BERT area, but >> apparently they are overlapped in some way. We will access the whole >> BERT area here via ioremap the whole range. > > This is the

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On Fri, Feb 17, 2017 at 03:30:51PM -0800, John Fastabend wrote: > On 17-02-16 09:10 PM, Jason Wang wrote: > > > > > > On 2017年02月17日 12:53, John Fastabend wrote: > >> On 17-02-15 01:08 AM, Jason Wang wrote: > >>> We set queues before reset which will cause a crash[1]. This is > >>> because

Re: [PATCH net-next] virito-net: set queues after reset during xdp_set

On Fri, Feb 17, 2017 at 03:30:51PM -0800, John Fastabend wrote: > On 17-02-16 09:10 PM, Jason Wang wrote: > > > > > > On 2017年02月17日 12:53, John Fastabend wrote: > >> On 17-02-15 01:08 AM, Jason Wang wrote: > >>> We set queues before reset which will cause a crash[1]. This is > >>> because

[GIT PULL] Block pull request for- 4.11-rc1

Hi Linus, This is the collected pull request for 4.11 for the block core and drivers. It's really two different branches: for-4.11/block-signed for-4.11/next-signed for-4.11/next exists because some of Christoph's patch series were based on patches that were added after

[GIT PULL] Block pull request for- 4.11-rc1

Hi Linus, This is the collected pull request for 4.11 for the block core and drivers. It's really two different branches: for-4.11/block-signed for-4.11/next-signed for-4.11/next exists because some of Christoph's patch series were based on patches that were added after

linux-next: manual merge of the kspp tree with the net-next tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: include/linux/filter.h between commit: 74451e66d516 ("bpf: make jited programs visible in traces") from the net-next tree and commit: 0f5bf6d0afe4 ("arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX")

linux-next: manual merge of the kspp tree with the net-next tree

Hi Kees, Today's linux-next merge of the kspp tree got a conflict in: include/linux/filter.h between commit: 74451e66d516 ("bpf: make jited programs visible in traces") from the net-next tree and commit: 0f5bf6d0afe4 ("arch: Rename CONFIG_DEBUG_RODATA and CONFIG_DEBUG_MODULE_RONX")

Re: [PATCH v2 2/3] watchdog: sama5d4: Fix setting timeout when watchdog is disabled

On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote: > > > That means if the watchdog is running, the timeout would not be updated. > > > It should be updated no matter if it is running or not. > > > > > > > No, it is enabling the watchdog, then changing WDV and WDD and finally > > disabling

Re: [PATCH v2 2/3] watchdog: sama5d4: Fix setting timeout when watchdog is disabled

On 19/02/2017 at 08:57:35 -0800, Guenter Roeck wrote: > > > That means if the watchdog is running, the timeout would not be updated. > > > It should be updated no matter if it is running or not. > > > > > > > No, it is enabling the watchdog, then changing WDV and WDD and finally > > disabling

linux-next: build warnings after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (arm multi_v7_defconfig) produced these warnings: drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe': drivers/gpu/drm/sti/sti_vtg.c:392:22: warning: unused variable 'np' [-Wunused-variable] struct device_node *np;

linux-next: build warnings after merge of the drm tree

Hi Dave, After merging the drm tree, today's linux-next build (arm multi_v7_defconfig) produced these warnings: drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe': drivers/gpu/drm/sti/sti_vtg.c:392:22: warning: unused variable 'np' [-Wunused-variable] struct device_node *np;

Re: linux-next: error fetching the ipmi tree

Hi Corey, On Sun, 19 Feb 2017 16:26:18 -0600 Corey Minyard wrote: > > Dang, I was hoping SourceForge had cleaned up their act. I can ask for > an account on > kernel.org, but I'm not sure I will be able to get one. Yeah, you need a well signed GPG key ... > I'm in the

Re: linux-next: error fetching the ipmi tree

Hi Corey, On Sun, 19 Feb 2017 16:26:18 -0600 Corey Minyard wrote: > > Dang, I was hoping SourceForge had cleaned up their act. I can ask for > an account on > kernel.org, but I'm not sure I will be able to get one. Yeah, you need a well signed GPG key ... > I'm in the process of moving

<    1   2   3   4   5   6   7   >