Re: [PATCH v3 0/6] power: add power sequence library

On Thu, Jul 28, 2016 at 08:56:40AM -0700, Joshua Clayton wrote: > Hi, Peter > > On 07/20/2016 02:40 AM, Peter Chen wrote: > > Hi all, > > > > This is a follow-up for my last power sequence framework patch set [1]. > > According to Rob Herring and Ulf Hansson's comments[2], I use a generic > >

[PATCH v4 1/2] tpm: devicetree: document properties for cr50

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. Signed-off-by: Andrey Pronin --- .../devicetree/bindings/security/tpm/cr50_spi.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644

Re: [PATCH v3 0/6] power: add power sequence library

On Thu, Jul 28, 2016 at 08:56:40AM -0700, Joshua Clayton wrote: > Hi, Peter > > On 07/20/2016 02:40 AM, Peter Chen wrote: > > Hi all, > > > > This is a follow-up for my last power sequence framework patch set [1]. > > According to Rob Herring and Ulf Hansson's comments[2], I use a generic > >

[PATCH v4 1/2] tpm: devicetree: document properties for cr50

Add TPM2.0 PTP FIFO compatible SPI interface for chips with Cr50 firmware. Signed-off-by: Andrey Pronin --- .../devicetree/bindings/security/tpm/cr50_spi.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/i915_debugfs.c between commit: 194dc870a589 ("Add braces to avoid "ambiguous ‘else’" compiler warnings") from Linus' tree and commit: 24f1d3cc0997 ("drm/i915: Refactor execlists default context

linux-next: manual merge of the drm tree with Linus' tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/i915_debugfs.c between commit: 194dc870a589 ("Add braces to avoid "ambiguous ‘else’" compiler warnings") from Linus' tree and commit: 24f1d3cc0997 ("drm/i915: Refactor execlists default context

[PATCH v3 7/7] doc: bindings: act8945a-charger: Update properties

Due the driver improvements, update the properties, - Remove "active-semi,check-battery-temperature" property. - Add the properties, "active-semi,irq_gpio" and "active-semi,lbo-gpios". Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None

[PATCH v3 7/7] doc: bindings: act8945a-charger: Update properties

Due the driver improvements, update the properties, - Remove "active-semi,check-battery-temperature" property. - Add the properties, "active-semi,irq_gpio" and "active-semi,lbo-gpios". Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None

[PATCH v3 6/7] power: act8945a_charger: Add max current property

Add the power supply's current max property, POWER_SUPPLY_PROP_CURRENT_MAX. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None drivers/power/act8945a_charger.c | 79 +++- 1 file changed, 77 insertions(+), 2

[PATCH v3 6/7] power: act8945a_charger: Add max current property

Add the power supply's current max property, POWER_SUPPLY_PROP_CURRENT_MAX. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None drivers/power/act8945a_charger.c | 79 +++- 1 file changed, 77 insertions(+), 2 deletions(-) diff --git

[PATCH v3 5/7] power: act8945a_charger: Add capacity level property

Add the power supply capacity level property, it corresponds to POWER_SUPPLY_CAPACITY_LEVEL_*. It also utilizes the precision voltage detector function module to catch the low battery voltage. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None

[PATCH v3 5/7] power: act8945a_charger: Add capacity level property

Add the power supply capacity level property, it corresponds to POWER_SUPPLY_CAPACITY_LEVEL_*. It also utilizes the precision voltage detector function module to catch the low battery voltage. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None

[PATCH v3 4/7] power: act8945a_charger: Fix the power supply type

The power supply type property is varying as the external power supply changes. It is not a constant. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None drivers/power/act8945a_charger.c | 48 1 file changed,

[PATCH v3 4/7] power: act8945a_charger: Fix the power supply type

The power supply type property is varying as the external power supply changes. It is not a constant. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None drivers/power/act8945a_charger.c | 48 1 file changed, 39 insertions(+), 9

[PATCH v3 3/7] power: act8945a_charger: Add status change update support

Add the charger status change interrupt support, it will report the power supply changed event. This interrupt is generated by one of the conditions as below: - the state machine jumps out of or into the EOC state - the CHGIN input voltage goes out of or into the valid range. - the battery

[PATCH v3 3/7] power: act8945a_charger: Add status change update support

Add the charger status change interrupt support, it will report the power supply changed event. This interrupt is generated by one of the conditions as below: - the state machine jumps out of or into the EOC state - the CHGIN input voltage goes out of or into the valid range. - the battery

[PATCH v3 2/7] power: act8945a_charger: Improve

When get the property, first check the charger state machine, then check the status bit to decide what value is assigned to the corresponding property. Retain the SUSCHG bit of REG 0x71 when configure the timers to avoid losting the charger suspending info after boot. Signed-off-by: Wenyou Yang

[PATCH v3 1/7] power: act8945a_charger: Remove "battery_temperature"

Remove "battery_temperature" member, it is redundant, it is the hardware's responsibility to handle TH pin properly. It is unnecessary to use the dt property to check if there is a battery temperature monitor or not. Signed-off-by: Wenyou Yang --- Changes in v3: None

[PATCH v3 2/7] power: act8945a_charger: Improve

When get the property, first check the charger state machine, then check the status bit to decide what value is assigned to the corresponding property. Retain the SUSCHG bit of REG 0x71 when configure the timers to avoid losting the charger suspending info after boot. Signed-off-by: Wenyou Yang

[PATCH v3 1/7] power: act8945a_charger: Remove "battery_temperature"

Remove "battery_temperature" member, it is redundant, it is the hardware's responsibility to handle TH pin properly. It is unnecessary to use the dt property to check if there is a battery temperature monitor or not. Signed-off-by: Wenyou Yang --- Changes in v3: None Changes in v2: None

[PATCH v3 0/7] power: act8945a_charger: Improvements

This patch series is used to improve the act8945a-charger, such as improve the way to check the status, fix the power supply type property, add the status change update, and add more properties: capacity level property and max current property. Changes in v3: - Remove unneeded semicolon to fix

[PATCH v3 0/7] power: act8945a_charger: Improvements

This patch series is used to improve the act8945a-charger, such as improve the way to check the status, fix the power supply type property, add the status change update, and add more properties: capacity level property and max current property. Changes in v3: - Remove unneeded semicolon to fix

[PATCH v4 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

This patch to add a generic PHY driver for rockchip PCIe PHY. Access the PHY via registers provided by GRF (general register files) module. Signed-off-by: Shawn Lin --- Changes in v4: - remove laneoff symbol as we still fail to get a workable solution except for

[PATCH v4 2/2] phy: add a driver for the Rockchip SoC internal PCIe PHY

This patch to add a generic PHY driver for rockchip PCIe PHY. Access the PHY via registers provided by GRF (general register files) module. Signed-off-by: Shawn Lin --- Changes in v4: - remove laneoff symbol as we still fail to get a workable solution except for exporting symbol. But I will

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, Jul 27, 2016 at 8:52 PM, Steven Rostedt wrote: > > I just looked at your patch. Would this work if you moved that > KBUILD_CFLAGS to the tracing directory? Something like the below (never > compiled or tested). I tried something like that, but the CFLAGS games the

[PATCH v4 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

This patch adds a binding that describes the Rockchip PCIe PHY found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin --- Changes in v4: None Changes in v3: - rename the node to pcie_phy: pcie-phy suggested by Doug Changes in v2: - add clk and reset

Re: warning: calling ‘__builtin_return_address’ with a nonzero argument is unsafe

On Wed, Jul 27, 2016 at 8:52 PM, Steven Rostedt wrote: > > I just looked at your patch. Would this work if you moved that > KBUILD_CFLAGS to the tracing directory? Something like the below (never > compiled or tested). I tried something like that, but the CFLAGS games the tracing code does made

[PATCH v4 1/2] Documentation: bindings: add dt documentation for Rockchip PCIe PHY

This patch adds a binding that describes the Rockchip PCIe PHY found on Rockchip SoCs PCIe interface. Signed-off-by: Shawn Lin --- Changes in v4: None Changes in v3: - rename the node to pcie_phy: pcie-phy suggested by Doug Changes in v2: - add clk and reset description - remove unit-address

Re: [PATCH] sched/core: add taint on "BUG: sleeping function called from invalid context"

Vegard Nossum writes: > Seeing this, it occurs to me that we should probably add a taint here: Taint has traditionally meant "the user did something unsupported, take the bug report with a grain of salt". Such as force removing a module. So this seems wrong...

Re: [PATCH] sched/core: add taint on "BUG: sleeping function called from invalid context"

Vegard Nossum writes: > Seeing this, it occurs to me that we should probably add a taint here: Taint has traditionally meant "the user did something unsupported, take the bug report with a grain of salt". Such as force removing a module. So this seems wrong... Cheers, Rusty. > > BUG:

Re: [PATCH] ses: Fix racy cleanup of /sys in remove_dev()

> "Calvin" == Calvin Owens writes: >> Any thoughts? Squinting at this more it still seems racy, but a >> narrow race is surely better than just blatantly freeing everything >> while the file is still exposed in /sys? Is there a better way you'd >> prefer I accomplish

Re: [PATCH] ses: Fix racy cleanup of /sys in remove_dev()

> "Calvin" == Calvin Owens writes: >> Any thoughts? Squinting at this more it still seems racy, but a >> narrow race is surely better than just blatantly freeing everything >> while the file is still exposed in /sys? Is there a better way you'd >> prefer I accomplish this? >> >> (I have

Re: [PATCH] lpfc: Fix possible NULL pointer dereference

> "James" == James Smart writes: James> This patch is good. Johannes: You were going to tweak a few things and resubmit. Please do. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] lpfc: Fix possible NULL pointer dereference

> "James" == James Smart writes: James> This patch is good. Johannes: You were going to tweak a few things and resubmit. Please do. -- Martin K. Petersen Oracle Linux Engineering

linux-next: build failure after merge of the vfs tree

Hi Al, After merging the vfs tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: fs/fuse/dir.c: In function 'fuse_reverse_inval_entry': fs/fuse/dir.c:958:13: error: assignment of member 'hash' in read-only object name->hash = full_name_hash(dir, name->name, name->len);

linux-next: build failure after merge of the vfs tree

Hi Al, After merging the vfs tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: fs/fuse/dir.c: In function 'fuse_reverse_inval_entry': fs/fuse/dir.c:958:13: error: assignment of member 'hash' in read-only object name->hash = full_name_hash(dir, name->name, name->len);

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

> "Eric" == Eric Wheeler writes: Eric, Eric> However, just because FADV_SEQUENTIAL is flagged doesn't mean the Eric> cache should bypass. Filesystems can fragment, and while the file Eric> being read may be read sequentially, the blocks on which it Eric> resides

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

> "Eric" == Eric Wheeler writes: Eric, Eric> However, just because FADV_SEQUENTIAL is flagged doesn't mean the Eric> cache should bypass. Filesystems can fragment, and while the file Eric> being read may be read sequentially, the blocks on which it Eric> resides may not be. Same thing for

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

On 29/07/16 01:50, Eric Wheeler wrote: > Hello all, > > With the many SSD caching layers being developed (bcache, dm-cache, > dm-writeboost, etc), how could we flag a bio from userspace to indicate > whether the bio is preferred to hit spinning disks instead of an SSD? > > Unnecessary

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

On 29/07/16 01:50, Eric Wheeler wrote: > Hello all, > > With the many SSD caching layers being developed (bcache, dm-cache, > dm-writeboost, etc), how could we flag a bio from userspace to indicate > whether the bio is preferred to hit spinning disks instead of an SSD? > > Unnecessary

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn()); > > > > > + vb->bmap_len = ALIGN(vb->pfn_limit,

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> > > On Wed, Jul 27, 2016 at 09:03:21AM -0700, Dave Hansen wrote: > > > > On 07/26/2016 06:23 PM, Liang Li wrote: > > > > > + vb->pfn_limit = VIRTIO_BALLOON_PFNS_LIMIT; > > > > > + vb->pfn_limit = min(vb->pfn_limit, get_max_pfn()); > > > > > + vb->bmap_len = ALIGN(vb->pfn_limit,

Re: [kbuild-all] [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

Hi Wenyou, On Fri, Jul 29, 2016 at 12:57:20AM +, Yang, Wenyou wrote: Hi Fengguang, I would like to merge this patch and add your Signed-off-by, do you agree? I think it is better. Yes that'd be fine, too. Thanks, Fengguang From: kbuild test robot [l...@intel.com] Sent: Friday, June

Re: [kbuild-all] [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

Hi Wenyou, On Fri, Jul 29, 2016 at 12:57:20AM +, Yang, Wenyou wrote: Hi Fengguang, I would like to merge this patch and add your Signed-off-by, do you agree? I think it is better. Yes that'd be fine, too. Thanks, Fengguang From: kbuild test robot [l...@intel.com] Sent: Friday, June

RE: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

Hi Fengguang, I would like to merge this patch and add your Signed-off-by, do you agree? I think it is better. Best Regards, Wenyou Yang From: kbuild test robot [l...@intel.com] Sent: Friday, June 24, 2016 20:43 To: Yang, Wenyou Cc: kbuild-...@01.org;

RE: [PATCH] power: act8945a_charger: fix semicolon.cocci warnings

Hi Fengguang, I would like to merge this patch and add your Signed-off-by, do you agree? I think it is better. Best Regards, Wenyou Yang From: kbuild test robot [l...@intel.com] Sent: Friday, June 24, 2016 20:43 To: Yang, Wenyou Cc: kbuild-...@01.org;

To add, or not to add, a bio REQ_ROTATIONAL flag

Hello all, With the many SSD caching layers being developed (bcache, dm-cache, dm-writeboost, etc), how could we flag a bio from userspace to indicate whether the bio is preferred to hit spinning disks instead of an SSD? Unnecessary promotions, evections, and writeback increase the write

To add, or not to add, a bio REQ_ROTATIONAL flag

Hello all, With the many SSD caching layers being developed (bcache, dm-cache, dm-writeboost, etc), how could we flag a bio from userspace to indicate whether the bio is preferred to hit spinning disks instead of an SSD? Unnecessary promotions, evections, and writeback increase the write

[RESEND PATCH 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

As per L2C-310 TRM[1]: "... You can control this feature using bits 30,27 and 23 of the Prefetch Control Register. Bit 23 and 27 are only used if you set bit 30 HIGH..." which means there is no need to clear bit 23 if bit 30 is being cleared. [1]

[RESEND PATCH 1/2] ARM: cache-l2x0.c: Replace magic numbers

Replace magic numbers used for L310 Prefetch Control Register Acked-by: Arnd Bergmann Signed-off-by: Andrey Smirnov --- arch/arm/mm/cache-l2x0.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c

[RESEND PATCH 2/2] ARM: cache-l2x0.c: Do not clear bit 23 in prefetch control register

As per L2C-310 TRM[1]: "... You can control this feature using bits 30,27 and 23 of the Prefetch Control Register. Bit 23 and 27 are only used if you set bit 30 HIGH..." which means there is no need to clear bit 23 if bit 30 is being cleared. [1]

[RESEND PATCH 1/2] ARM: cache-l2x0.c: Replace magic numbers

Replace magic numbers used for L310 Prefetch Control Register Acked-by: Arnd Bergmann Signed-off-by: Andrey Smirnov --- arch/arm/mm/cache-l2x0.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c index 9f9d542..30e2012

Re: [PATCH v2 0/3] ntb: Asynchronous NTB devices support

Hello, Allen. Thanks for the message. I see your point. Yes, I've seen a lot of cruel threads in mailing threads in lkml.org , so it's not my intention to argue about basic things like Coding Style. That's why I left most of the warnings discussable. While you a digging into the Patch 1/3, I'll do

Re: [PATCH v2 0/3] ntb: Asynchronous NTB devices support

Hello, Allen. Thanks for the message. I see your point. Yes, I've seen a lot of cruel threads in mailing threads in lkml.org , so it's not my intention to argue about basic things like Coding Style. That's why I left most of the warnings discussable. While you a digging into the Patch 1/3, I'll do

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 06:36:18AM +, Li, Liang Z wrote: > > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > > > How big was the pfn buffer before? > > > > > > > > Yes, it is if the max pfn is more than 32GB. > > > > The size of the pfn buffer use before is

RE: [virtio-dev] Re: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 06:36:18AM +, Li, Liang Z wrote: > > > > > This ends up doing a 1MB kmalloc() right? That seems a _bit_ big. > > > > > How big was the pfn buffer before? > > > > > > > > Yes, it is if the max pfn is more than 32GB. > > > > The size of the pfn buffer use before is

RE: [PATCH] mtd: spi-nor: Add at25df321 spi-nor flash support

> -Original Message- > From: Jagan Teki [mailto:jt...@openedev.com] > Sent: 2016年7月26日 16:38 > To: linux-...@lists.infradead.org > Cc: David Woodhouse ; linux-kernel@vger.kernel.org; > Jagan Teki ; Brian Norris > ;

RE: [PATCH] mtd: spi-nor: Add at25df321 spi-nor flash support

> -Original Message- > From: Jagan Teki [mailto:jt...@openedev.com] > Sent: 2016年7月26日 16:38 > To: linux-...@lists.infradead.org > Cc: David Woodhouse ; linux-kernel@vger.kernel.org; > Jagan Teki ; Brian Norris > ; Wenyou Yang > Subject: [PATCH] mtd: spi-nor: Add at25df321 spi-nor flash

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 03:06:37AM +, Li, Liang Z wrote: > > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page > > > > +bitmap > > > > + * to prevent a very large page bitmap, there are two reasons for this: > > > > + * 1) to save memory. > > > > + * 2) allocate a large

RE: [PATCH v2 repost 4/7] virtio-balloon: speed up inflate/deflate process

> On Thu, Jul 28, 2016 at 03:06:37AM +, Li, Liang Z wrote: > > > > + * VIRTIO_BALLOON_PFNS_LIMIT is used to limit the size of page > > > > +bitmap > > > > + * to prevent a very large page bitmap, there are two reasons for this: > > > > + * 1) to save memory. > > > > + * 2) allocate a large

[PATCH 0/3] objtool warning fixes

Fixes for some objtool-related warnings reported by Linus. Josh Poimboeuf (3): objtool: support new gcc 6 switch jump table pattern objtool: resync x86 instruction decoder with the kernel's objtool: un-capitalize "Warning" for out-of-sync instruction decoder tools/objtool/Makefile

[PATCH 2/3] objtool: resync x86 instruction decoder with the kernel's

This fixes the following warning: Warning: objtool: x86 instruction decoder differs from kernel Unfortunately we have three identical copies of the x86 instruction decoder in the kernel tree that have to be manually kept in sync. It's on my TODO list to at least library-ize the ones in the

[PATCH 0/3] objtool warning fixes

Fixes for some objtool-related warnings reported by Linus. Josh Poimboeuf (3): objtool: support new gcc 6 switch jump table pattern objtool: resync x86 instruction decoder with the kernel's objtool: un-capitalize "Warning" for out-of-sync instruction decoder tools/objtool/Makefile

[PATCH 2/3] objtool: resync x86 instruction decoder with the kernel's

This fixes the following warning: Warning: objtool: x86 instruction decoder differs from kernel Unfortunately we have three identical copies of the x86 instruction decoder in the kernel tree that have to be manually kept in sync. It's on my TODO list to at least library-ize the ones in the

[PATCH 3/3] objtool: un-capitalize "Warning" for out-of-sync instruction decoder

Change "Warning" to "warning" to make it look more like a gcc warning. Hopefully that will be enough to help the 0-day bot or other automated tools catch this warning earlier before it ends up in Linus's tree. Reported-by: Linus Torvalds Reviewed-by: Josh Poimboeuf

[PATCH 3/3] objtool: un-capitalize "Warning" for out-of-sync instruction decoder

Change "Warning" to "warning" to make it look more like a gcc warning. Hopefully that will be enough to help the 0-day bot or other automated tools catch this warning earlier before it ends up in Linus's tree. Reported-by: Linus Torvalds Reviewed-by: Josh Poimboeuf --- tools/objtool/Makefile |

[PATCH 1/3] objtool: support new gcc 6 switch jump table pattern

This fixes some false positive objtool warnings seen with gcc 6.1.1: kernel/trace/ring_buffer.o: warning: objtool: ring_buffer_read_page()+0x36c: sibling call from callable instruction with changed frame pointer arch/x86/kernel/reboot.o: warning: objtool:

[PATCH 1/3] objtool: support new gcc 6 switch jump table pattern

This fixes some false positive objtool warnings seen with gcc 6.1.1: kernel/trace/ring_buffer.o: warning: objtool: ring_buffer_read_page()+0x36c: sibling call from callable instruction with changed frame pointer arch/x86/kernel/reboot.o: warning: objtool:

Re: [PATCH 1/3] Add a new field to struct shrinker

On Thu, Jul 28, 2016 at 11:25:13AM +0100, Mel Gorman wrote: > On Thu, Jul 28, 2016 at 03:49:47PM +1000, Dave Chinner wrote: > > Seems you're all missing the obvious. > > > > Add a tracepoint for a shrinker callback that includes a "name" > > field, have the shrinker callback fill it out

Re: [PATCH 1/3] Add a new field to struct shrinker

On Thu, Jul 28, 2016 at 11:25:13AM +0100, Mel Gorman wrote: > On Thu, Jul 28, 2016 at 03:49:47PM +1000, Dave Chinner wrote: > > Seems you're all missing the obvious. > > > > Add a tracepoint for a shrinker callback that includes a "name" > > field, have the shrinker callback fill it out

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

This is completely untested (and probably horribly broken/buggy), but here's a quick mockup of the general approach I was thinking for ensuring DDB & WM's can be updated together while ensuring the three-step pipe flushing process is honored:

Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks

This is completely untested (and probably horribly broken/buggy), but here's a quick mockup of the general approach I was thinking for ensuring DDB & WM's can be updated together while ensuring the three-step pipe flushing process is honored:

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Thu, Jul 28, 2016 at 6:41 AM, Theodore Ts'o wrote: > On Thu, Jul 28, 2016 at 09:24:08AM +0200, Heiko Carstens wrote: >> >> Oh, I just realized that Linus pulled your changes. Actually I was hoping >> we could get this fixed before the broken code would be merged. >> Could you

Re: [BUG -next] "random: make /dev/urandom scalable for silly userspace programs" causes crash

On Thu, Jul 28, 2016 at 6:41 AM, Theodore Ts'o wrote: > On Thu, Jul 28, 2016 at 09:24:08AM +0200, Heiko Carstens wrote: >> >> Oh, I just realized that Linus pulled your changes. Actually I was hoping >> we could get this fixed before the broken code would be merged. >> Could you please make sure

Re: [PATCH v4 2/2] input: add ADC resistor ladder driver

On Fri, Jul 29, 2016 at 12:49:21AM +0200, Alexandre Belloni wrote: > On 28/07/2016 at 15:09:18 -0700, Dmitry Torokhov wrote : > > On Tue, Jul 12, 2016 at 05:41:50PM -0700, Dmitry Torokhov wrote: > > > Hi Alexandre, > > > > > > On Tue, Jul 12, 2016 at 09:36:26PM +0200, Alexandre Belloni wrote: > >

Re: [PATCH v4 2/2] input: add ADC resistor ladder driver

On Fri, Jul 29, 2016 at 12:49:21AM +0200, Alexandre Belloni wrote: > On 28/07/2016 at 15:09:18 -0700, Dmitry Torokhov wrote : > > On Tue, Jul 12, 2016 at 05:41:50PM -0700, Dmitry Torokhov wrote: > > > Hi Alexandre, > > > > > > On Tue, Jul 12, 2016 at 09:36:26PM +0200, Alexandre Belloni wrote: > >

Re: [PATCH v2 05/13] gpu: ipu-v3: Add IDMA channel linking support

On 07/26/2016 03:06 AM, Philipp Zabel wrote: Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam: Adds functions to link and unlink IDMAC source channels to sink channels. So far the following links are supported: IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC

Re: [PATCH v2 05/13] gpu: ipu-v3: Add IDMA channel linking support

On 07/26/2016 03:06 AM, Philipp Zabel wrote: Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam: Adds functions to link and unlink IDMAC source channels to sink channels. So far the following links are supported: IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC

[PATCH 1/5] ipc/msg: Implement lockless pipelined wakeups

From: Sebastian Andrzej Siewior This patch moves the wakeup_process() invocation so it is not done under the ipc global lock by making use of a lockless wake_q. With this change, the waiter is woken up once the message has been assigned and it does not need to loop on SMP

[PATCH 1/5] ipc/msg: Implement lockless pipelined wakeups

From: Sebastian Andrzej Siewior This patch moves the wakeup_process() invocation so it is not done under the ipc global lock by making use of a lockless wake_q. With this change, the waiter is woken up once the message has been assigned and it does not need to loop on SMP if the message points

[PATCH 0/5] ipc/msg: Sender/receiver optimizations

Hi, I'm resending Sebastian's sysv msg queue use of wake_qs but updated to the last observations I need wrt the need of explicit barriers after removing the whole receiver busy-looping. After some irc exchange it seems we're both on the same page, and things now look like he had them earlier, in

[PATCH 0/5] ipc/msg: Sender/receiver optimizations

Hi, I'm resending Sebastian's sysv msg queue use of wake_qs but updated to the last observations I need wrt the need of explicit barriers after removing the whole receiver busy-looping. After some irc exchange it seems we're both on the same page, and things now look like he had them earlier, in

[PATCH 3/5] ipc/msg: Make ss_wakeup() kill arg boolean

... 'tis annoying. Signed-off-by: Davidlohr Bueso --- ipc/msg.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ipc/msg.c b/ipc/msg.c index 395013d58fda..5181259e2ff0 100644 --- a/ipc/msg.c +++ b/ipc/msg.c @@ -167,7 +167,7 @@ static inline void

[PATCH 2/5] ipc/msg: Batch queue sender wakeups

Currently the use of wake_qs in sysv msg queues are only for the receiver tasks that are blocked on the queue. But blocked sender tasks (due to queue size constraints) still are awoken with the ipc object lock held, which can be a problem particularly for small sized queues and far from gracious

[PATCH 3/5] ipc/msg: Make ss_wakeup() kill arg boolean

... 'tis annoying. Signed-off-by: Davidlohr Bueso --- ipc/msg.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ipc/msg.c b/ipc/msg.c index 395013d58fda..5181259e2ff0 100644 --- a/ipc/msg.c +++ b/ipc/msg.c @@ -167,7 +167,7 @@ static inline void ss_del(struct

[PATCH 2/5] ipc/msg: Batch queue sender wakeups

Currently the use of wake_qs in sysv msg queues are only for the receiver tasks that are blocked on the queue. But blocked sender tasks (due to queue size constraints) still are awoken with the ipc object lock held, which can be a problem particularly for small sized queues and far from gracious

[PATCH 4/5] ipc/msg: Lockless security checks for msgsnd

Just as with msgrcv (along with the rest of sysvipc since a few years ago), perform the security checks without holding the ipc object lock. This also reduces the hogging of the lock for the entire duration of a sender, as we drop the lock upon every iteration -- and this is exactly why we also

[PATCH 4/5] ipc/msg: Lockless security checks for msgsnd

Just as with msgrcv (along with the rest of sysvipc since a few years ago), perform the security checks without holding the ipc object lock. This also reduces the hogging of the lock for the entire duration of a sender, as we drop the lock upon every iteration -- and this is exactly why we also

[PATCH 5/5] ipc/msg: Avoid waking sender upon full queue

Blocked tasks queued in q_senders waiting for their message to fit in the queue are blindly awoken every time we think there's a remote chance this might happen. This could cause numerous (and expensive -- thundering herd-ish) bogus wakeups if the queue is still really full. Adding to the

mmotm 2016-07-28-16-33 uploaded

The mm-of-the-moment snapshot 2016-07-28-16-33 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

[PATCH 5/5] ipc/msg: Avoid waking sender upon full queue

Blocked tasks queued in q_senders waiting for their message to fit in the queue are blindly awoken every time we think there's a remote chance this might happen. This could cause numerous (and expensive -- thundering herd-ish) bogus wakeups if the queue is still really full. Adding to the

mmotm 2016-07-28-16-33 uploaded

The mm-of-the-moment snapshot 2016-07-28-16-33 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

Re: [Intel-wired-lan] [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Eric Dumazet : [...] > I would prefer having a definitive advice from Thomas Gleixner and/or > others if disable_irq() is forbidden from IRQ path. > > As I said, about all netpoll() methods in net drivers use disable_irq() > so a lot of patches would be needed. s/about

Re: [Intel-wired-lan] [e1000_netpoll] BUG: sleeping function called from invalid context at kernel/irq/manage.c:110

Eric Dumazet : [...] > I would prefer having a definitive advice from Thomas Gleixner and/or > others if disable_irq() is forbidden from IRQ path. > > As I said, about all netpoll() methods in net drivers use disable_irq() > so a lot of patches would be needed. s/about all/many/ There has been

Re: [RFC] ath10k: silence firmware file probing warnings

On Thu, Jul 28, 2016 at 09:23:35PM +0200, Arend van Spriel wrote: > On 23-07-16 00:05, Luis R. Rodriguez wrote: > > The firmware API is a mess and I've been trying to correct that > > with a more flexible API. <-- snip --> > > Extensions to the fw API are IMHO best done through a newer flexible

Re: [RFC] ath10k: silence firmware file probing warnings

On Thu, Jul 28, 2016 at 09:23:35PM +0200, Arend van Spriel wrote: > On 23-07-16 00:05, Luis R. Rodriguez wrote: > > The firmware API is a mess and I've been trying to correct that > > with a more flexible API. <-- snip --> > > Extensions to the fw API are IMHO best done through a newer flexible

Re: [PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]

On Thu, 23 Jun 2016, David Howells wrote: diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h index 8ac2c5fbc8fc..93ebd25b1427 100644 --- a/include/uapi/linux/keyctl.h +++ b/include/uapi/linux/keyctl.h @@ -60,6 +60,11 @@ #define KEYCTL_INVALIDATE 21 /*

Re: [PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]

On Thu, 23 Jun 2016, David Howells wrote: diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h index 8ac2c5fbc8fc..93ebd25b1427 100644 --- a/include/uapi/linux/keyctl.h +++ b/include/uapi/linux/keyctl.h @@ -60,6 +60,11 @@ #define KEYCTL_INVALIDATE 21 /*

Re: [PATCH v3 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 28, 2016 at 04:01:41PM -0700, Dmitry Torokhov wrote: > > + u8 tx_buf[MAX_SPI_FRAMESIZE]; > > + u8 rx_buf[MAX_SPI_FRAMESIZE]; > > Both of these need to be annotated as "cacheline_aligned" since we > eye them for use in DMA transfers. Huh. That sure looks true to me.. We make

Re: [PATCH v3 2/2] tpm: add driver for cr50 on SPI

On Thu, Jul 28, 2016 at 04:01:41PM -0700, Dmitry Torokhov wrote: > > + u8 tx_buf[MAX_SPI_FRAMESIZE]; > > + u8 rx_buf[MAX_SPI_FRAMESIZE]; > > Both of these need to be annotated as "cacheline_aligned" since we > eye them for use in DMA transfers. Huh. That sure looks true to me.. We make

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