Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

> Kirill points out that the calls to {get,put}_dev_pagemap() can be > removed from the mm fast path if we take a single get_dev_pagemap() > reference to signify that the page is alive and use the final put of the > page to drop that reference. > > This does require some care to make sure that

Re: [PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

> Kirill points out that the calls to {get,put}_dev_pagemap() can be > removed from the mm fast path if we take a single get_dev_pagemap() > reference to signify that the page is alive and use the final put of the > page to drop that reference. > > This does require some care to make sure that

Re: 4.11-rc8 makes my Dell Inspiron 5558 crash

On Thu, Apr 27, 2017 at 8:09 PM, Diego Viola wrote: > On Thu, Apr 27, 2017 at 7:56 PM, Diego Viola wrote: >> Hello, >> >> For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The >> problem is very random and I don't know how to reproduce it.

Re: 4.11-rc8 makes my Dell Inspiron 5558 crash

On Thu, Apr 27, 2017 at 8:09 PM, Diego Viola wrote: > On Thu, Apr 27, 2017 at 7:56 PM, Diego Viola wrote: >> Hello, >> >> For some reason 4.11-rc8 makes my Dell Inspiron 5558 crash. The >> problem is very random and I don't know how to reproduce it. >> >> That said, this only started happening

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On 28/04/17 17:52, Will Deacon wrote: > On Fri, Apr 28, 2017 at 06:16:46PM +0200, Geert Uytterhoeven wrote: >> On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: >>> On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: On arm32, the machine model

[PATCH] mwifiex: pcie: add card_reset() support

Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: Brian Norris --- I still haven't found the reset sequence to work 100% reliably, but it's definitely better

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On 28/04/17 17:52, Will Deacon wrote: > On Fri, Apr 28, 2017 at 06:16:46PM +0200, Geert Uytterhoeven wrote: >> On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: >>> On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: On arm32, the machine model specified in the device

[PATCH] mwifiex: pcie: add card_reset() support

Similar to the SDIO driver, we should implement this so that we will automatically reset the device whenever there's a command timeout or similar. Signed-off-by: Brian Norris --- I still haven't found the reset sequence to work 100% reliably, but it's definitely better than nothing.

[PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

Kirill points out that the calls to {get,put}_dev_pagemap() can be removed from the mm fast path if we take a single get_dev_pagemap() reference to signify that the page is alive and use the final put of the page to drop that reference. This does require some care to make sure that any waits for

[PATCH v2] mm, zone_device: replace {get, put}_zone_device_page() with a single reference

Kirill points out that the calls to {get,put}_dev_pagemap() can be removed from the mm fast path if we take a single get_dev_pagemap() reference to signify that the page is alive and use the final put of the page to drop that reference. This does require some care to make sure that any waits for

Re: [PATCH 2/2] Input: twl4030-pwrbutton: Use input_set_capability() helper

On Fri, Apr 28, 2017 at 02:28:55PM +0200, Sebastian Reichel wrote: > Cleanup driver slightly by using input_set_capability() instead > of manually setting the required bits. > > Signed-off-by: Sebastian Reichel Applied, thank you. > --- >

Re: [PATCH 2/2] Input: twl4030-pwrbutton: Use input_set_capability() helper

On Fri, Apr 28, 2017 at 02:28:55PM +0200, Sebastian Reichel wrote: > Cleanup driver slightly by using input_set_capability() instead > of manually setting the required bits. > > Signed-off-by: Sebastian Reichel Applied, thank you. > --- > drivers/input/misc/twl4030-pwrbutton.c | 3 +-- > 1

Re: [PATCH 1/2] Input: twl4030-pwrbutton: use correct device for irq request

On Fri, Apr 28, 2017 at 02:28:54PM +0200, Sebastian Reichel wrote: > The interrupt should be requested for the platform device > and not for the input device. > > Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using > devm_*") > Signed-off-by: Sebastian Reichel

Re: [PATCH 1/2] Input: twl4030-pwrbutton: use correct device for irq request

On Fri, Apr 28, 2017 at 02:28:54PM +0200, Sebastian Reichel wrote: > The interrupt should be requested for the platform device > and not for the input device. > > Fixes: 7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using > devm_*") > Signed-off-by: Sebastian Reichel Applied, thank

Re: [PATCH v2 4/4] perf vendor events arm64: Add implementation defined pmu core events of ThunderX2

On Fri, Apr 28, 2017 at 10:23:47AM +0530, Ganapatrao Kulkarni wrote: > This is not a full event list, but a short list of useful events. > > Signed-off-by: Ganapatrao Kulkarni > --- > tools/perf/pmu-events/arch/arm64/mapfile.csv | 14 + >

Re: [PATCH v2 4/4] perf vendor events arm64: Add implementation defined pmu core events of ThunderX2

On Fri, Apr 28, 2017 at 10:23:47AM +0530, Ganapatrao Kulkarni wrote: > This is not a full event list, but a short list of useful events. > > Signed-off-by: Ganapatrao Kulkarni > --- > tools/perf/pmu-events/arch/arm64/mapfile.csv | 14 + >

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > currently running v4.11-rc8-75-gf83246089ca0 > > sunrpc bit is for the other unrelated problem I'm chasing. > > note also, I saw the backtrace without the fs/splice.c changes. Interesting... Could you add this and see if

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 12:50:24PM -0400, Dave Jones wrote: > currently running v4.11-rc8-75-gf83246089ca0 > > sunrpc bit is for the other unrelated problem I'm chasing. > > note also, I saw the backtrace without the fs/splice.c changes. Interesting... Could you add this and see if

Re: [PATCH 1/3] IB/i40iw: use setup_timer

On Sat, 2017-04-22 at 09:32 +0800, Geliang Tang wrote: > Use setup_timer() instead of init_timer() to simplify the code. > > Signed-off-by: Geliang Tang Thanks, series applied. -- Doug Ledford     GPG KeyID: B826A3330E572FDD     Key fingerprint =

Re: [PATCH 1/3] IB/i40iw: use setup_timer

On Sat, 2017-04-22 at 09:32 +0800, Geliang Tang wrote: > Use setup_timer() instead of init_timer() to simplify the code. > > Signed-off-by: Geliang Tang Thanks, series applied. -- Doug Ledford     GPG KeyID: B826A3330E572FDD     Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

On 26/04/17 17:03, Suzuki K Poulose wrote: On 25/04/17 19:49, Radim Krčmář wrote: 2017-04-24 11:10+0100, Suzuki K Poulose: The KVM uses mmu_notifier (wherever available) to keep track of the changes to the mm of the guest. The guest shadow page tables are released when the VM exits via

Re: [PATCH 1/2] kvm: Fix mmu_notifier release race

On 26/04/17 17:03, Suzuki K Poulose wrote: On 25/04/17 19:49, Radim Krčmář wrote: 2017-04-24 11:10+0100, Suzuki K Poulose: The KVM uses mmu_notifier (wherever available) to keep track of the changes to the mm of the guest. The guest shadow page tables are released when the VM exits via

Re: [PATCH] tpm: print tpm error code in hex for TPM2.0 devices

On Fri Apr 28 17, Jarkko Sakkinen wrote: On Wed, Apr 26, 2017 at 03:39:54PM -0700, Jerry Snitselaar wrote: For easier decoding, output the error code returned from the tpm device in hex when the device is TPM2.0. Cc: Jarkko Sakkinen Cc: Peter Huewe

Re: [PATCH] tpm: print tpm error code in hex for TPM2.0 devices

On Fri Apr 28 17, Jarkko Sakkinen wrote: On Wed, Apr 26, 2017 at 03:39:54PM -0700, Jerry Snitselaar wrote: For easier decoding, output the error code returned from the tpm device in hex when the device is TPM2.0. Cc: Jarkko Sakkinen Cc: Peter Huewe Cc: Marcel Selhorst Cc: Jason Gunthorpe

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

On 28/04/17 18:08, Doug Ledford wrote: > On Mon, 2017-04-24 at 10:44 -0700, Joe Perches wrote: >> On Mon, 2017-04-24 at 10:26 +0100, Colin King wrote: >>> >>> trivial fix to typo in pr_err message >> [] >>> >>> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c >>>

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

On 28/04/17 18:08, Doug Ledford wrote: > On Mon, 2017-04-24 at 10:44 -0700, Joe Perches wrote: >> On Mon, 2017-04-24 at 10:26 +0100, Colin King wrote: >>> >>> trivial fix to typo in pr_err message >> [] >>> >>> diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c >>>

Re: [PATCH v2 3/5] mtd: gpmi: document current clock requirements

On Fri, Apr 21, 2017 at 06:23:36PM -0700, Stefan Agner wrote: > The clock requirements are completely missing, add the clocks > currently required by the driver. > > Signed-off-by: Stefan Agner > --- > Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +- > 1

Re: [PATCH v2 3/5] mtd: gpmi: document current clock requirements

On Fri, Apr 21, 2017 at 06:23:36PM -0700, Stefan Agner wrote: > The clock requirements are completely missing, add the clocks > currently required by the driver. > > Signed-off-by: Stefan Agner > --- > Documentation/devicetree/bindings/mtd/gpmi-nand.txt | 14 +- > 1 file changed, 13

Re: [PATCH] streamline TLV320AIC23 drivers

On Fri, Apr 21, 2017 at 09:22:02PM +0200, Jens Rottmann wrote: > The iMX-TLV320AIC23 driver isn't from Freescale, but from a company named > Eukrea Electromatique, originally for their own boards. From the code I get > the impression it is a bit older, its DT options use a differing naming >

Re: [PATCH] streamline TLV320AIC23 drivers

On Fri, Apr 21, 2017 at 09:22:02PM +0200, Jens Rottmann wrote: > The iMX-TLV320AIC23 driver isn't from Freescale, but from a company named > Eukrea Electromatique, originally for their own boards. From the code I get > the impression it is a bit older, its DT options use a differing naming >

Re: [PATCH 1/1] iw_cxgb4: check return value of alloc_skb

On Sun, 2017-04-23 at 17:09 +0800, Pan Bian wrote: > Function alloc_skb() will return a NULL pointer when there is no > enough > memory. However, the return value of alloc_skb() is directly used > without validation in function send_fw_pass_open_req(). This patches > checks the return value of

Re: [PATCH 1/1] iw_cxgb4: check return value of alloc_skb

On Sun, 2017-04-23 at 17:09 +0800, Pan Bian wrote: > Function alloc_skb() will return a NULL pointer when there is no > enough > memory. However, the return value of alloc_skb() is directly used > without validation in function send_fw_pass_open_req(). This patches > checks the return value of

Re: [PATCH v2] sched/fair: update scale invariance of PELT

On 28/04/17 16:52, Morten Rasmussen wrote: > Hi Vincent, [...] > As mentioned above, waiting time, i.e. !running && weight, is not > scaled, which causes trouble for load. I ran some rt-app-based tests on a system with frequency and cpu invariance. (1) Two periodic 20% tasks with 12ms period

Re: [PATCH v2] sched/fair: update scale invariance of PELT

On 28/04/17 16:52, Morten Rasmussen wrote: > Hi Vincent, [...] > As mentioned above, waiting time, i.e. !running && weight, is not > scaled, which causes trouble for load. I ran some rt-app-based tests on a system with frequency and cpu invariance. (1) Two periodic 20% tasks with 12ms period

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

On Mon, 2017-04-24 at 10:44 -0700, Joe Perches wrote: > On Mon, 2017-04-24 at 10:26 +0100, Colin King wrote: > > > > trivial fix to typo in pr_err message > [] > > > > diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c > > b/drivers/infiniband/sw/rxe/rxe_verbs.c > [] > > > > @@ -1324,7 +1324,7

Re: [PATCH][V2] IB/rxe: fix typo: "algorithmi" -> "algorithm"

On Mon, 2017-04-24 at 10:44 -0700, Joe Perches wrote: > On Mon, 2017-04-24 at 10:26 +0100, Colin King wrote: > > > > trivial fix to typo in pr_err message > [] > > > > diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c > > b/drivers/infiniband/sw/rxe/rxe_verbs.c > [] > > > > @@ -1324,7 +1324,7

Re: [PATCH 2/2] input: touchscreen: ar1021_i2c: replace magic number with definition

On Thu, Apr 27, 2017 at 02:22:36PM +0200, Martin Kepplinger wrote: > We now have a few of this device's definitions. Let's avoid magic numbers > and use them. > > Signed-off-by: Martin Kepplinger > --- > drivers/input/touchscreen/ar1021_i2c.c | 2 +- > 1 file

Re: [PATCH 2/2] input: touchscreen: ar1021_i2c: replace magic number with definition

On Thu, Apr 27, 2017 at 02:22:36PM +0200, Martin Kepplinger wrote: > We now have a few of this device's definitions. Let's avoid magic numbers > and use them. > > Signed-off-by: Martin Kepplinger > --- > drivers/input/touchscreen/ar1021_i2c.c | 2 +- > 1 file changed, 1 insertion(+), 1

[PATCH] crypto: hifn_795x: Fix a handful of minor bugs spotted by eye

* Cleaned up the formatting of ablkcipher_get arguments so it complies with kernel style * The offset in ablkcipher_get sould be added to the source, not the destination. We rename it to soffset for clarity. * dst++ should be dst=sg_next(dst) * We call kunmap_atomic earlier so we only have to

[PATCH] crypto: hifn_795x: Fix a handful of minor bugs spotted by eye

* Cleaned up the formatting of ablkcipher_get arguments so it complies with kernel style * The offset in ablkcipher_get sould be added to the source, not the destination. We rename it to soffset for clarity. * dst++ should be dst=sg_next(dst) * We call kunmap_atomic earlier so we only have to

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

On Thu, Apr 27, 2017 at 02:22:35PM +0200, Martin Kepplinger wrote: > The device could as well be in command mode, in which this driver cannot > handle the device. When opening the device, let's make sure the device > will be in the mode we expect it to be for this driver. > > Signed-off-by:

Re: [PATCH 1/2] input: touchscreen: ar1021_i2c: enable touch mode during open

On Thu, Apr 27, 2017 at 02:22:35PM +0200, Martin Kepplinger wrote: > The device could as well be in command mode, in which this driver cannot > handle the device. When opening the device, let's make sure the device > will be in the mode we expect it to be for this driver. > > Signed-off-by:

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Fri, Apr 28, 2017 at 06:16:46PM +0200, Geert Uytterhoeven wrote: > On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: > > On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > >> On arm32, the machine model specified in the device tree is printed > >>

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Fri, Apr 28, 2017 at 06:16:46PM +0200, Geert Uytterhoeven wrote: > On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: > > On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > >> On arm32, the machine model specified in the device tree is printed > >> during boot-up, courtesy

Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

On Tue, Mar 21, 2017 at 02:14:05PM +0200, Kalle Valo wrote: > What I could do is to wait for the patches 1-3 trickle down to w-d-next > and then apply this patch. It usually takes few weeks, but with bad luck > it might happen only after the merge window. Would that work? Is this going to get

Re: [4/4] mwifiex: pcie: de-duplicate buffer allocation code

On Tue, Mar 21, 2017 at 02:14:05PM +0200, Kalle Valo wrote: > What I could do is to wait for the patches 1-3 trickle down to w-d-next > and then apply this patch. It usually takes few weeks, but with bad luck > it might happen only after the merge window. Would that work? Is this going to get

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 05:43:13PM +0100, Al Viro wrote: > On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote: > > On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > > > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > > > > > Well it's been running an

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 05:43:13PM +0100, Al Viro wrote: > On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote: > > On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > > > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > > > > > Well it's been running an

Re: [PATCH v2] power: tps65217_charger: Add properties like voltage and current charge

On Fri, Apr 21, 2017 at 05:50:32PM +0200, Enric Balletbo i Serra wrote: > Allow the possibility to configure the charge and the current voltage of > the charger and also the NTC type for battery temperature measurement. > > Signed-off-by: Enric Balletbo i Serra >

Re: [PATCH v2] power: tps65217_charger: Add properties like voltage and current charge

On Fri, Apr 21, 2017 at 05:50:32PM +0200, Enric Balletbo i Serra wrote: > Allow the possibility to configure the charge and the current voltage of > the charger and also the NTC type for battery temperature measurement. > > Signed-off-by: Enric Balletbo i Serra > --- > Changes since v1: > -

Re: ipsec doesn't route TCP with 4.11 kernel

On Fri, 2017-04-28 at 09:13 +0200, Steffen Klassert wrote: > encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 > > Ok, this is espinudp. This information was important. > This is not a GRO issue as I thought, the TX side is already broken. > > Could you please try the patch below?

Re: ipsec doesn't route TCP with 4.11 kernel

On Fri, 2017-04-28 at 09:13 +0200, Steffen Klassert wrote: > encap type espinudp sport 4500 dport 4500 addr 0.0.0.0 > > Ok, this is espinudp. This information was important. > This is not a GRO issue as I thought, the TX side is already broken. > > Could you please try the patch below?

RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Friday, April 28, 2017, Andy Shevchenko wrote: > > We were using "input-enable" to signal when the pin function that we set > also needs to be forcible set to input by the software (once again, > because the HW is not smart enough to do it on its own), but is different > than the bi-directional

RE: [PATCH v5 01/10] pinctrl: generic: Add bi-directional and output-enable

On Friday, April 28, 2017, Andy Shevchenko wrote: > > We were using "input-enable" to signal when the pin function that we set > also needs to be forcible set to input by the software (once again, > because the HW is not smart enough to do it on its own), but is different > than the bi-directional

Re: [PATCH] staging: ks7010: remove line continuations in quoted strings

On Fri, 2017-04-28 at 17:26 +0300, Dan Carpenter wrote: > On Fri, Apr 28, 2017 at 04:19:28PM +0200, Ilia Sergachev wrote: > > Checkpatch emits WARNING: Avoid line continuations in quoted strings. > > > > Remove line continuations - split strings using quotes. > > > > Signed-off-by: Ilia

Re: [PATCH] staging: ks7010: remove line continuations in quoted strings

On Fri, 2017-04-28 at 17:26 +0300, Dan Carpenter wrote: > On Fri, Apr 28, 2017 at 04:19:28PM +0200, Ilia Sergachev wrote: > > Checkpatch emits WARNING: Avoid line continuations in quoted strings. > > > > Remove line continuations - split strings using quotes. > > > > Signed-off-by: Ilia

Re: linux-next: Tree for Apr 28 (of/unittest)

On 04/28/17 00:11, Stephen Rothwell wrote: > Hi all, > > Changes since 20170427: > on i386: when CONFIG_OF_OVERLAY is not enabled: drivers/built-in.o: In function `unflatten_device_tree': (.init.text+0x1209f): undefined reference to `unittest_unflatten_overlay_base' -- ~Randy

Re: linux-next: Tree for Apr 28 (of/unittest)

On 04/28/17 00:11, Stephen Rothwell wrote: > Hi all, > > Changes since 20170427: > on i386: when CONFIG_OF_OVERLAY is not enabled: drivers/built-in.o: In function `unflatten_device_tree': (.init.text+0x1209f): undefined reference to `unittest_unflatten_overlay_base' -- ~Randy

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote: > On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > > > Well it's been running an hour without incident, which looks promising. > > > I'll leave it run, but

Re: iov_iter_pipe warning.

On Fri, Apr 28, 2017 at 11:29:55AM -0400, Dave Jones wrote: > On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > > > Well it's been running an hour without incident, which looks promising. > > > I'll leave it run, but

Re: [PATCH v1]] lib/btree.c: optimise the code by previously getpos function

On Tue, Apr 11, 2017 at 9:53 AM, Leno Hou wrote: > This patch optimized the code by previously getpos function call. > Therefore, It's takes the convenience to understand logic of code. Besides what Christoph told you (I agree with him, writing test suites / modules is quite

Re: [PATCH v1]] lib/btree.c: optimise the code by previously getpos function

On Tue, Apr 11, 2017 at 9:53 AM, Leno Hou wrote: > This patch optimized the code by previously getpos function call. > Therefore, It's takes the convenience to understand logic of code. Besides what Christoph told you (I agree with him, writing test suites / modules is quite good exercise for

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

Hi guys, On Fri, Apr 28, 2017 at 01:46:24PM +, Jayachandran C wrote: > On Thu, Apr 27, 2017 at 06:37:59PM +0100, Will Deacon wrote: > > > If my understanding is correct, the sysfs suggestion above is going to > > > add API complexity without solving the issue. Ignoring the exclude_hv if > > >

Re: [PATCH v2] arm64: perf: Use only exclude_kernel attribute when kernel is running in HYP

Hi guys, On Fri, Apr 28, 2017 at 01:46:24PM +, Jayachandran C wrote: > On Thu, Apr 27, 2017 at 06:37:59PM +0100, Will Deacon wrote: > > > If my understanding is correct, the sysfs suggestion above is going to > > > add API complexity without solving the issue. Ignoring the exclude_hv if > > >

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 01:11 AM, Jon Masters wrote: > On 04/27/2017 08:54 PM, Khuong Dinh wrote: >> From: Khuong Dinh >> >> This patch makes pci-xgene-msi driver ACPI-aware and provides >> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. >> >> Signed-off-by: Khuong Dinh

Re: [PATCH v2 pci] PCI/MSI: pci-xgene-msi: Enable MSI support in ACPI boot for X-Gene v1

On 04/28/2017 01:11 AM, Jon Masters wrote: > On 04/27/2017 08:54 PM, Khuong Dinh wrote: >> From: Khuong Dinh >> >> This patch makes pci-xgene-msi driver ACPI-aware and provides >> MSI capability for X-Gene v1 PCIe controllers in ACPI boot mode. >> >> Signed-off-by: Khuong Dinh >> Signed-off-by:

Re: [PATCH 2/3] selinux: add checksum to policydb

On Fri, 2017-04-28 at 18:08 +0200, Sebastien Buisson wrote: > 2017-04-28 17:50 GMT+02:00 Stephen Smalley : > > You seem to be conflating kernel policy with userspace policy. > > security_load_policy() is provided with the kernel policy image, > > which > > is the result of

Re: [PATCH 2/3] selinux: add checksum to policydb

On Fri, 2017-04-28 at 18:08 +0200, Sebastien Buisson wrote: > 2017-04-28 17:50 GMT+02:00 Stephen Smalley : > > You seem to be conflating kernel policy with userspace policy. > > security_load_policy() is provided with the kernel policy image, > > which > > is the result of linking the

Re: [PATCH 1/2] mtd: nand: add generic helpers to check, match, maximize ECC settings

Hi Masahiro, Sorry for the delay, I was busy with non-NAND/MTD stuff lately. On Wed, 19 Apr 2017 16:06:57 +0900 Masahiro Yamada wrote: > Each driver has been responsible for: > - Check if ECC setting specified (mostly by DT) is valid > - Meet the chip's

Re: [PATCH 1/2] mtd: nand: add generic helpers to check, match, maximize ECC settings

Hi Masahiro, Sorry for the delay, I was busy with non-NAND/MTD stuff lately. On Wed, 19 Apr 2017 16:06:57 +0900 Masahiro Yamada wrote: > Each driver has been responsible for: > - Check if ECC setting specified (mostly by DT) is valid > - Meet the chip's required ECC strength > - Maximize

Re: [PATCH v7 1/3] staging: typec: USB Type-C Port Manager (tcpm)

On Fri, Apr 28, 2017 at 8:50 AM, Greg Kroah-Hartman wrote: > On Fri, Apr 28, 2017 at 06:14:44AM -0700, Guenter Roeck wrote: >> On 04/28/2017 12:28 AM, Greg Kroah-Hartman wrote: >> > On Thu, Apr 27, 2017 at 02:09:56PM -0700, Guenter Roeck wrote: >> > > --- /dev/null >>

Re: [PATCH v7 1/3] staging: typec: USB Type-C Port Manager (tcpm)

On Fri, Apr 28, 2017 at 8:50 AM, Greg Kroah-Hartman wrote: > On Fri, Apr 28, 2017 at 06:14:44AM -0700, Guenter Roeck wrote: >> On 04/28/2017 12:28 AM, Greg Kroah-Hartman wrote: >> > On Thu, Apr 27, 2017 at 02:09:56PM -0700, Guenter Roeck wrote: >> > > --- /dev/null >> > > +++

Re: Boot regression caused by kauditd

On Fri, Apr 28, 2017 at 12:11 PM, Cong Wang wrote: > On Fri, Apr 28, 2017 at 8:30 AM, Paul Moore wrote: >> On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: >>> In that case please send a proper inline patch to the audit

Re: Boot regression caused by kauditd

On Fri, Apr 28, 2017 at 12:11 PM, Cong Wang wrote: > On Fri, Apr 28, 2017 at 8:30 AM, Paul Moore wrote: >> On Thu, Apr 27, 2017 at 8:47 PM, Paul Moore wrote: >>> In that case please send a proper inline patch to the audit mailing list >>> and we'll review it. >>> >>> Thanks. >> >> Now that I'm

Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Fri, Apr 28, 2017 at 11:16 AM, Linus Walleij wrote: > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > But why. > > I have these two static inlines just below your new macros: +1. > We generally prefer static inlines over macros

Re: [PATCH v5 02/10] pinctrl: generic: Add macros to unpack properties

On Fri, Apr 28, 2017 at 11:16 AM, Linus Walleij wrote: > On Thu, Apr 27, 2017 at 10:19 AM, Jacopo Mondi > wrote: > But why. > > I have these two static inlines just below your new macros: +1. > We generally prefer static inlines over macros because they are easier > to read. Not only. It

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

2017-04-25, 20:47:30 +0200, Jason A. Donenfeld wrote: > This is a defense-in-depth measure in response to bugs like > 4d6fa57b4dab ("macsec: avoid heap overflow in skb_to_sgvec"). While > we're at it, we also limit the amount of recursion this function is > allowed to do. Not actually providing a

Re: [PATCH] staging: iio: isl29028: add isl29030 support

On Fri, Apr 28, 2017 at 05:55:58PM +0200, Sebastian Reichel wrote: > isl29030 is basically the same chip. The only difference > is the chip's first pin. For isl29028 its named ADDR0 and > can be used to change the chip's i2c address. For isl29030 > on the other hand that pin is named Ials and is

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

Hi Will, On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: > On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: >> On arm32, the machine model specified in the device tree is printed >> during boot-up, courtesy of of_flat_dt_match_machine(). >> >> On

Re: [PATCH] staging: iio: isl29028: add isl29030 support

On Fri, Apr 28, 2017 at 05:55:58PM +0200, Sebastian Reichel wrote: > isl29030 is basically the same chip. The only difference > is the chip's first pin. For isl29028 its named ADDR0 and > can be used to change the chip's i2c address. For isl29030 > on the other hand that pin is named Ials and is

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

Hi Will, On Fri, Apr 28, 2017 at 4:57 PM, Will Deacon wrote: > On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: >> On arm32, the machine model specified in the device tree is printed >> during boot-up, courtesy of of_flat_dt_match_machine(). >> >> On arm64,

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 169

[PATCH 1/7] crypto: aesni: make non-AVX AES-GCM work with any aadlen

This is the first step to make the aesni AES-GCM implementation generic. The current code was written for rfc4106, so it handles only some specific sizes of associated data. Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 169 +- 1 file

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index

[PATCH 2/7] crypto: aesni: make non-AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_asm.S | 62 ++- 1 file changed, 48 insertions(+), 14 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S index 605726aaf0a2..16627fec80b2 100644 ---

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, Vincent. On Thu, Apr 27, 2017 at 10:28:01AM +0200, Vincent Guittot wrote: > On 27 April 2017 at 02:30, Tejun Heo wrote: > > Hello, Vincent. > > > > On Wed, Apr 26, 2017 at 12:21:52PM +0200, Vincent Guittot wrote: > >> > This is from the follow-up patch. I was confused.

Re: [PATCH 2/2] sched/fair: Always propagate runnable_load_avg

Hello, Vincent. On Thu, Apr 27, 2017 at 10:28:01AM +0200, Vincent Guittot wrote: > On 27 April 2017 at 02:30, Tejun Heo wrote: > > Hello, Vincent. > > > > On Wed, Apr 26, 2017 at 12:21:52PM +0200, Vincent Guittot wrote: > >> > This is from the follow-up patch. I was confused. Because we don't

[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index

[PATCH 6/7] crypto: aesni: make AVX2 AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index 7230808a7cef..faecb1518bf8

Re: RFC: i2c designware gpio recovery

Hi After sending this mail i just found out how i could reset the i2c-1 controller manually with devmem 0xffd05014 32 0x2000 devmem 0xffd05014 32 0 So i took a look into the device tree file socfpga.dtsi and found that the reset lines where not defined (although available in the corresponding

Re: RFC: i2c designware gpio recovery

Hi After sending this mail i just found out how i could reset the i2c-1 controller manually with devmem 0xffd05014 32 0x2000 devmem 0xffd05014 32 0 So i took a look into the device tree file socfpga.dtsi and found that the reset lines where not defined (although available in the corresponding

Re: [PATCH] drivers: dma-mapping: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()

On Tue, Apr 25, 2017 at 07:25:49PM +0100, Catalin Marinas wrote: > On Tue, Apr 25, 2017 at 07:22:23PM +0100, Catalin Marinas wrote: > > The dma_common_pages_remap() function allocates a vm_struct object and > > initialises the pages pointer to value passed as argument. However, when > > this

Re: [PATCH] drivers: dma-mapping: Do not leave an invalid area->pages pointer in dma_common_contiguous_remap()

On Tue, Apr 25, 2017 at 07:25:49PM +0100, Catalin Marinas wrote: > On Tue, Apr 25, 2017 at 07:22:23PM +0100, Catalin Marinas wrote: > > The dma_common_pages_remap() function allocates a vm_struct object and > > initialises the pages pointer to value passed as argument. However, when > > this

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index

[PATCH 4/7] crypto: aesni: make AVX AES-GCM work with all valid auth_tag_len

Signed-off-by: Sabrina Dubroca --- arch/x86/crypto/aesni-intel_avx-x86_64.S | 31 --- 1 file changed, 24 insertions(+), 7 deletions(-) diff --git a/arch/x86/crypto/aesni-intel_avx-x86_64.S b/arch/x86/crypto/aesni-intel_avx-x86_64.S index a73117c84904..ee6283120f83

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > On arm32, the machine model specified in the device tree is printed > during boot-up, courtesy of of_flat_dt_match_machine(). > > On arm64, of_flat_dt_match_machine() is not called, and the machine > model information is not

Re: [PATCH] arm64: Print DT machine model in setup_machine_fdt()

On Thu, Apr 27, 2017 at 02:33:05PM +0200, Geert Uytterhoeven wrote: > On arm32, the machine model specified in the device tree is printed > during boot-up, courtesy of of_flat_dt_match_machine(). > > On arm64, of_flat_dt_match_machine() is not called, and the machine > model information is not

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