Re: [PATCH 1/1] gpu: drm: qxl: fix use of uninitialized variable

On Sat, Dec 3, 2016 at 10:11 AM, Pan Bian wrote: > In function qxl_release_alloc(), when kmalloc() returns a NULL pointer, > it returns value 0 and parameter *ret is uninitialized. 0 means no error > to the callers of qxl_release_alloc(). The callers keep going and will > try

Re: [PATCH 1/1] gpu: drm: qxl: fix use of uninitialized variable

On Sat, Dec 3, 2016 at 10:11 AM, Pan Bian wrote: > In function qxl_release_alloc(), when kmalloc() returns a NULL pointer, > it returns value 0 and parameter *ret is uninitialized. 0 means no error > to the callers of qxl_release_alloc(). The callers keep going and will > try to reference the

Re: [PATCH] net: ping: check minimum size on ICMP header length

From: Kees Cook Date: Fri, 2 Dec 2016 16:58:53 -0800 > diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c > index 205e2000d395..8257be3f032c 100644 > --- a/net/ipv4/ping.c > +++ b/net/ipv4/ping.c > @@ -654,7 +654,7 @@ int ping_common_sendmsg(int family, struct msghdr *msg, >

Re: [PATCH] net: ping: check minimum size on ICMP header length

From: Kees Cook Date: Fri, 2 Dec 2016 16:58:53 -0800 > diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c > index 205e2000d395..8257be3f032c 100644 > --- a/net/ipv4/ping.c > +++ b/net/ipv4/ping.c > @@ -654,7 +654,7 @@ int ping_common_sendmsg(int family, struct msghdr *msg, > size_t len, >

Re: [PATCH 0/8] irda: w83977af_ir: Neatening

On Thu, 2016-11-24 at 11:10 -0800, Joe Perches wrote: > On top of Arnd's overly long udelay patch because I noticed a > misindented block. > > Even though I haven't turned on the netwinder in a box in in the > garage in who knows how long, if this device is still used somewhere, > might as well

Re: [PATCH 0/8] irda: w83977af_ir: Neatening

On Thu, 2016-11-24 at 11:10 -0800, Joe Perches wrote: > On top of Arnd's overly long udelay patch because I noticed a > misindented block. > > Even though I haven't turned on the netwinder in a box in in the > garage in who knows how long, if this device is still used somewhere, > might as well

Re: [PATCH] arm: kprobe: replace patch_lock to raw lock

On 12/1/2016 6:13 AM, Sebastian Andrzej Siewior wrote: On 2016-11-10 16:17:55 [-0800], Yang Shi wrote: Since patch_text_stop_machine() is called in stop_machine() which disables IRQ, sleepable lock should be not used in this atomic context, so replace patch_lock to raw lock. Signed-off-by:

Re: [PATCH] arm: kprobe: replace patch_lock to raw lock

On 12/1/2016 6:13 AM, Sebastian Andrzej Siewior wrote: On 2016-11-10 16:17:55 [-0800], Yang Shi wrote: Since patch_text_stop_machine() is called in stop_machine() which disables IRQ, sleepable lock should be not used in this atomic context, so replace patch_lock to raw lock. Signed-off-by:

Re: [PATCH v2] net: phy: dp83848: Support ethernet pause frames

From: Jesper Nilsson Date: Fri, 2 Dec 2016 15:57:49 +0100 > According to the documentation, the PHYs supported by this driver > can also support pause frames. Announce this to be so. > Tested with a TI83822I. > > Acked-by: Andrew F. Davis > Signed-off-by:

Re: [PATCH v2] net: phy: dp83848: Support ethernet pause frames

From: Jesper Nilsson Date: Fri, 2 Dec 2016 15:57:49 +0100 > According to the documentation, the PHYs supported by this driver > can also support pause frames. Announce this to be so. > Tested with a TI83822I. > > Acked-by: Andrew F. Davis > Signed-off-by: Jesper Nilsson Applied to net-next,

Re: bio linked list corruption.

On Sun, Dec 4, 2016 at 3:04 PM, Vegard Nossum wrote: > On 23 November 2016 at 20:58, Dave Jones wrote: >> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote: >> >> > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4

Re: bio linked list corruption.

On Sun, Dec 4, 2016 at 3:04 PM, Vegard Nossum wrote: > On 23 November 2016 at 20:58, Dave Jones wrote: >> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote: >> >> > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4 >> > trace from just before this happened. Does

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 5, 2016 at 10:02 AM, Jason Gunthorpe wrote: > On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote: > >> > If it is kernel only with physical addresess we don't need a uAPI for >> > it, so I'm not sure #1 is at all related to iopmem. >> > >> >

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 5, 2016 at 10:02 AM, Jason Gunthorpe wrote: > On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote: > >> > If it is kernel only with physical addresess we don't need a uAPI for >> > it, so I'm not sure #1 is at all related to iopmem. >> > >> > Most people who want #1 probably

Re: [patch net v3] net: fec: fix compile with CONFIG_M5272

> +#define FEC_STATS_SIZE (ARRAY_SIZE(fec_stats) * sizeof(u64)) > > > Do I take it right this actually translates to (sizeof(fec_stats) / > sizeof(u64) * sizeof(u64))? No. fec_stats is an array of structs, each struct has car arrsy and integer, and size of that is definitely not

Re: [patch net v3] net: fec: fix compile with CONFIG_M5272

> +#define FEC_STATS_SIZE (ARRAY_SIZE(fec_stats) * sizeof(u64)) > > > Do I take it right this actually translates to (sizeof(fec_stats) / > sizeof(u64) * sizeof(u64))? No. fec_stats is an array of structs, each struct has car arrsy and integer, and size of that is definitely not

Re: [PATCH v5] soc: qcom: Add SoC info driver

On Wed 16 Nov 05:22 PST 2016, Imran Khan wrote: > The SoC info driver provides information such as Chip ID, > Chip family, serial number and other such details about > Qualcomm SoCs. > > Signed-off-by: Imran Khan > --- > v4 --> v5: > - Removed redundant function

Re: [PATCH v5] soc: qcom: Add SoC info driver

On Wed 16 Nov 05:22 PST 2016, Imran Khan wrote: > The SoC info driver provides information such as Chip ID, > Chip family, serial number and other such details about > Qualcomm SoCs. > > Signed-off-by: Imran Khan > --- > v4 --> v5: > - Removed redundant function socinfo_print > > v3 --> v4: >

Re: [PATCH] Input: synaptics-rmi4 - fix debug for sensor clip

On 12/04/2016 05:04 PM, Nick Dyer wrote: The debug would only ever output zero for the clip information. Signed-off-by: Nick Dyer Reviewed-by: Andrew Duggan --- drivers/input/rmi4/rmi_f12.c | 7 ++- 1 file changed, 2 insertions(+), 5

Re: [PATCH] Input: synaptics-rmi4 - fix debug for sensor clip

On 12/04/2016 05:04 PM, Nick Dyer wrote: The debug would only ever output zero for the clip information. Signed-off-by: Nick Dyer Reviewed-by: Andrew Duggan --- drivers/input/rmi4/rmi_f12.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote: > > If it is kernel only with physical addresess we don't need a uAPI for > > it, so I'm not sure #1 is at all related to iopmem. > > > > Most people who want #1 probably can just mmap > > /sys/../pci/../resourceX to get a user handle

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 05, 2016 at 09:40:38AM -0800, Dan Williams wrote: > > If it is kernel only with physical addresess we don't need a uAPI for > > it, so I'm not sure #1 is at all related to iopmem. > > > > Most people who want #1 probably can just mmap > > /sys/../pci/../resourceX to get a user handle

donating $850,000

My Wife and I have decided to make sure this is put on the Internet for the World to see, you CAN Visit this website for More Information on Our Charity Donation http://www.bbc.com/news/uk-scotland-glasgow-west-18801698 You Reply NAME ADDRESS MOBILE AGE COUNTY

donating $850,000

My Wife and I have decided to make sure this is put on the Internet for the World to see, you CAN Visit this website for More Information on Our Charity Donation http://www.bbc.com/news/uk-scotland-glasgow-west-18801698 You Reply NAME ADDRESS MOBILE AGE COUNTY

Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

Am 05.12.2016 um 17:02 schrieb Radim Krčmář: 2016-12-05 15:37+0100, David Hildenbrand: Am 02.12.2016 um 20:44 schrieb Radim Krčmář: LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of VCPUs with high APIC ID, because reset VCPU is waiting for INIT/SIPI, but there is no way

Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

Am 05.12.2016 um 17:02 schrieb Radim Krčmář: 2016-12-05 15:37+0100, David Hildenbrand: Am 02.12.2016 um 20:44 schrieb Radim Krčmář: LAPIC after reset is in xAPIC mode, which poses a problem for hotplug of VCPUs with high APIC ID, because reset VCPU is waiting for INIT/SIPI, but there is no way

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

On Mon, 5 Dec 2016, Paul Burton wrote: > Agreed we ought to use .set reorder (or rather, not use .set noreorder) > wherever possible but FYI one thing I've only noticed recently is that we > don't actually get any reordering anyway, presumably because we don't provide > any -O flags when

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

On Mon, 5 Dec 2016, Paul Burton wrote: > Agreed we ought to use .set reorder (or rather, not use .set noreorder) > wherever possible but FYI one thing I've only noticed recently is that we > don't actually get any reordering anyway, presumably because we don't provide > any -O flags when

Re: [PATCH 1/7] net: ethernet: ti: cpdma: am437x: allow descs to be plased in ddr

On 12/03/2016 02:34 PM, David Miller wrote: > From: Grygorii Strashko > Date: Thu, 1 Dec 2016 17:34:26 -0600 > >> @@ -167,10 +167,10 @@ static struct cpdma_control_info controls[] = { >> >> /* various accessors */ >> #define dma_reg_read(ctlr, ofs)

Re: [PATCH 1/7] net: ethernet: ti: cpdma: am437x: allow descs to be plased in ddr

On 12/03/2016 02:34 PM, David Miller wrote: > From: Grygorii Strashko > Date: Thu, 1 Dec 2016 17:34:26 -0600 > >> @@ -167,10 +167,10 @@ static struct cpdma_control_info controls[] = { >> >> /* various accessors */ >> #define dma_reg_read(ctlr, ofs) __raw_readl((ctlr)->dmaregs +

Re: bio linked list corruption.

On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum wrote: > > The warning shows that it made it past the list_empty_careful() check > in finish_wait() but then bugs out on the >task_list > dereference. > > Anything stick out? I hate that shmem waitqueue garbage. It's really

Re: bio linked list corruption.

On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum wrote: > > The warning shows that it made it past the list_empty_careful() check > in finish_wait() but then bugs out on the >task_list > dereference. > > Anything stick out? I hate that shmem waitqueue garbage. It's really subtle. I think the

Re: [PATCH] crypto: rsa - fix a potential race condition in build

On 12/4/2016 10:48 PM, Herbert Xu wrote: On Fri, Dec 02, 2016 at 03:41:04PM -0800, Yang Shi wrote: When building kernel with RSA enabled with multithreaded, the below compile failure might be caught: | /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error: rsapubkey-asn1.h: No such

Re: [PATCH] crypto: rsa - fix a potential race condition in build

On 12/4/2016 10:48 PM, Herbert Xu wrote: On Fri, Dec 02, 2016 at 03:41:04PM -0800, Yang Shi wrote: When building kernel with RSA enabled with multithreaded, the below compile failure might be caught: | /buildarea/kernel-source/crypto/rsa_helper.c:18:28: fatal error: rsapubkey-asn1.h: No such

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On systems with sufficiently large e820 tables, and several IOAPICs, it is possible for the XENMEM_machine_memory_map callback (and its counterpart, XENMEM_memory_map) to attempt to return an e820 table with more than 128 entries. This callback adds entries to the BIOS-provided e820 table to

[PATCH 2/2] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

On systems with sufficiently large e820 tables, and several IOAPICs, it is possible for the XENMEM_machine_memory_map callback (and its counterpart, XENMEM_memory_map) to attempt to return an e820 table with more than 128 entries. This callback adds entries to the BIOS-provided e820 table to

[RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

This is the third pass at my patchset to fix up our problems with XENMEM_machine_memory_map on large systems. The only changes on this pass were to flesh out the comment above the E820_X_MAX definition, and to add Juergen's Reviewed-by to the second patch. Let me know if anyone has any

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

It's really not necessary to limit E820_X_MAX to 128 in the non-EFI case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that E820_X_MAX is always at least slightly larger than E820MAX. The real motivation behind this is actually to prevent some issues in the Xen kernel, where the

[PATCH v2] add equivalent of BIT(x) for bitfields

Introduce GENVALUE(msb, lsb, value) macro to ease dealing with continuous bitfields, just as BIT(x) does for single bits. GENVALUE_ULL(msb, lsb, value) macro is also added. This is useful mostly for creating values to be packed together via OR operations, ex: u32 val = 0x; val |=

[RFC PATCH v3] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries

This is the third pass at my patchset to fix up our problems with XENMEM_machine_memory_map on large systems. The only changes on this pass were to flesh out the comment above the E820_X_MAX definition, and to add Juergen's Reviewed-by to the second patch. Let me know if anyone has any

[PATCH 1/2] x86: Make E820_X_MAX unconditionally larger than E820MAX

It's really not necessary to limit E820_X_MAX to 128 in the non-EFI case. This commit drops E820_X_MAX's dependency on CONFIG_EFI, so that E820_X_MAX is always at least slightly larger than E820MAX. The real motivation behind this is actually to prevent some issues in the Xen kernel, where the

[PATCH v2] add equivalent of BIT(x) for bitfields

Introduce GENVALUE(msb, lsb, value) macro to ease dealing with continuous bitfields, just as BIT(x) does for single bits. GENVALUE_ULL(msb, lsb, value) macro is also added. This is useful mostly for creating values to be packed together via OR operations, ex: u32 val = 0x; val |=

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote: > Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with > continuous bitfields, just as BIT(x) does for single bits. If it's a bitfield, why not calling it that way? So what about BITFIELD(start ,size), like

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On Mon, Dec 5, 2016 at 2:36 PM, Sebastian Frias wrote: > Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with > continuous bitfields, just as BIT(x) does for single bits. If it's a bitfield, why not calling it that way? So what about BITFIELD(start ,size), like

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:13, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> SETBITFIELD_ULL(msb, lsb, value) macro is

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 18:13, Linus Torvalds wrote: > On Mon, Dec 5, 2016 at 5:36 AM, Sebastian Frias wrote: >> Introduce SETBITFIELD(msb, lsb, value) macro to ease dealing with >> continuous bitfields, just as BIT(x) does for single bits. >> >> SETBITFIELD_ULL(msb, lsb, value) macro is also added. > > No.

Re: [PATCH v9 00/12] Add Mediated device support

Hi, > Just want to share that we have published a KVMGT implementation > based on this v9 patchset, to: > > https://github.com/01org/gvt-linux/tree/gvt-next-kvmgt > > It doesn't utilize common routines introduced by 05+ patches yet. > The complete intel vGPU device-model is contained.

Re: [PATCH v9 00/12] Add Mediated device support

Hi, > Just want to share that we have published a KVMGT implementation > based on this v9 patchset, to: > > https://github.com/01org/gvt-linux/tree/gvt-next-kvmgt > > It doesn't utilize common routines introduced by 05+ patches yet. > The complete intel vGPU device-model is contained.

[PATCH 130/130] Fixed to checkpatch errors.

Hello, Fixed to checkpatch errors. ERROR: net/wireless/util.c:1787: ERROR: that open brace { should be on the previous line ERROR: net/wireless/util.c:1792: ERROR: that open brace { should be on the previous line Signed-off-by: Ozgur Karatas --- net/wireless/util.c

[PATCH 130/130] Fixed to checkpatch errors.

Hello, Fixed to checkpatch errors. ERROR: net/wireless/util.c:1787: ERROR: that open brace { should be on the previous line ERROR: net/wireless/util.c:1792: ERROR: that open brace { should be on the previous line Signed-off-by: Ozgur Karatas --- net/wireless/util.c | 10 ++ 1 file

[patch net v3] net: fec: fix compile with CONFIG_M5272

Commit 4dfb80d18d05 ("net: fec: cache statistics while device is down") introduced unconditional statistics-related actions. However, when driver is compiled with CONFIG_M5272, staticsics-related definitions do not exist, which results into build errors. Fix that by adding explicit handling of

[patch net v3] net: fec: fix compile with CONFIG_M5272

Commit 4dfb80d18d05 ("net: fec: cache statistics while device is down") introduced unconditional statistics-related actions. However, when driver is compiled with CONFIG_M5272, staticsics-related definitions do not exist, which results into build errors. Fix that by adding explicit handling of

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 5, 2016 at 9:18 AM, Jason Gunthorpe wrote: > On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote: >> Hi All >> >> This has been a great thread (thanks to Alex for kicking it off) and I >> wanted to jump in and maybe try and put some summary

Re: Enabling peer to peer device transactions for PCIe devices

On Mon, Dec 5, 2016 at 9:18 AM, Jason Gunthorpe wrote: > On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote: >> Hi All >> >> This has been a great thread (thanks to Alex for kicking it off) and I >> wanted to jump in and maybe try and put some summary around the >> discussion. I also

[PATCH v5 1/2] Add OV5647 device tree documentation

Add device tree documentation. Signed-off-by: Ramiro Oliveira --- .../devicetree/bindings/media/i2c/ov5647.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt diff --git

[PATCH v5 1/2] Add OV5647 device tree documentation

Add device tree documentation. Signed-off-by: Ramiro Oliveira --- .../devicetree/bindings/media/i2c/ov5647.txt | 19 +++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5647.txt diff --git

[PATCH v5 2/2] Add support for OV5647 sensor

Add support for OV5647 sensor. Modes supported: - 640x480 RAW 8 Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 866

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On Mon, 05 Dec 2016, Oleg Nesterov wrote: Yes. But percpu_down_write() should not be used after exit_notify(), so we can rely on rcu_read_lock(), release_task()->call_rcu(delayed_put_task_struct) can't be called until an exiting task passes exit_notify(). But then we probably need

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On Mon, 05 Dec 2016, Oleg Nesterov wrote: Yes. But percpu_down_write() should not be used after exit_notify(), so we can rely on rcu_read_lock(), release_task()->call_rcu(delayed_put_task_struct) can't be called until an exiting task passes exit_notify(). But then we probably need

[PATCH v5 2/2] Add support for OV5647 sensor

Add support for OV5647 sensor. Modes supported: - 640x480 RAW 8 Signed-off-by: Ramiro Oliveira --- MAINTAINERS| 7 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile | 1 + drivers/media/i2c/ov5647.c | 866 + 4

[PATCH v5 0/2] Add support for Omnivision OV5647

Hello, This patch adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in Raw 8. This is the fifth version of the OV5647 camera driver patchset. v5: - Refactor code - Change comments - Add missing error handling in some functions v4: - Add correct

[PATCH v5 0/2] Add support for Omnivision OV5647

Hello, This patch adds support for the Omnivision OV5647 sensor. At the moment it only supports 640x480 in Raw 8. This is the fifth version of the OV5647 camera driver patchset. v5: - Refactor code - Change comments - Add missing error handling in some functions v4: - Add correct

Re: [PATCH] uapi glibc compat: fix outer guard of net device flags enum

On Sat, Dec 03, 2016 at 05:31:45PM +0100, Jonas Gorski wrote: > Fix a wrong condition preventing the higher net device flags > IFF_LOWER_UP etc to be defined if net/if.h is included before > linux/if.h. > > The comment makes it clear the intention was to allow partial > definition with either

Re: [PATCH] uapi glibc compat: fix outer guard of net device flags enum

On Sat, Dec 03, 2016 at 05:31:45PM +0100, Jonas Gorski wrote: > Fix a wrong condition preventing the higher net device flags > IFF_LOWER_UP etc to be defined if net/if.h is included before > linux/if.h. > > The comment makes it clear the intention was to allow partial > definition with either

Re: [PATCH] Staging: comedi: kcomedilib: Add module_init/exit function

On 05/12/16 16:57, Cheah Kok Cheong wrote: Add init/exit function to follow LKM semantics. Apparently this module can still load/unload without the init/exit function. Tested loading/unloading with and without this patch. Signed-off-by: Cheah Kok Cheong ---

Re: [PATCH] Staging: comedi: kcomedilib: Add module_init/exit function

On 05/12/16 16:57, Cheah Kok Cheong wrote: Add init/exit function to follow LKM semantics. Apparently this module can still load/unload without the init/exit function. Tested loading/unloading with and without this patch. Signed-off-by: Cheah Kok Cheong ---

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

From: Nikita Yushchenko Date: Mon, 5 Dec 2016 20:26:52 +0300 >> From: Nikita Yushchenko >> Date: Mon, 5 Dec 2016 16:55:04 +0300 >> >>> Aieee I was typing too fast today, sorry... >>> >>> send separate "fix for the fix", or

Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja wrote: > > > On 12/02/2016 09:33 PM, Sean Paul wrote: >> >> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja >> wrote: >>> >>> Hi, >>> >>> On 12/02/2016 08:02 AM, zain wang wrote: We will

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

From: Nikita Yushchenko Date: Mon, 5 Dec 2016 20:26:52 +0300 >> From: Nikita Yushchenko >> Date: Mon, 5 Dec 2016 16:55:04 +0300 >> >>> Aieee I was typing too fast today, sorry... >>> >>> send separate "fix for the fix", or re-send patch without that silly typo? >> >> If the patch hasn't

Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja wrote: > > > On 12/02/2016 09:33 PM, Sean Paul wrote: >> >> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja >> wrote: >>> >>> Hi, >>> >>> On 12/02/2016 08:02 AM, zain wang wrote: We will ignored PSR setting if panel not support it. So,

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

> From: Nikita Yushchenko > Date: Mon, 5 Dec 2016 16:55:04 +0300 > >> Aieee I was typing too fast today, sorry... >> >> send separate "fix for the fix", or re-send patch without that silly typo? > > If the patch hasn't been applied yet, you resend a fixed

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

> From: Nikita Yushchenko > Date: Mon, 5 Dec 2016 16:55:04 +0300 > >> Aieee I was typing too fast today, sorry... >> >> send separate "fix for the fix", or re-send patch without that silly typo? > > If the patch hasn't been applied yet, you resend a fixed version of the > patch, always. Ok,

Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file

On Mon, Dec 5, 2016 at 9:25 AM, Serge Semin wrote: > On Mon, Dec 05, 2016 at 08:46:21AM -0600, Rob Herring wrote: >> On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote: >> > See cover-letter for changelog >> > >> > Signed-off-by: Serge Semin

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

Hi Maciej, > Overall I think all code should be using the (default) > `.set reorder' mode, perhaps forced explicitly in case these macros are > pasted into `.set noreorder' code, to make it easier to avoid subtle data > dependency bugs, and also to make R6 porting easier. Except maybe for the

Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file

On Mon, Dec 5, 2016 at 9:25 AM, Serge Semin wrote: > On Mon, Dec 05, 2016 at 08:46:21AM -0600, Rob Herring wrote: >> On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote: >> > See cover-letter for changelog >> > >> > Signed-off-by: Serge Semin >> > >> > --- >> >

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

Hi Maciej, > Overall I think all code should be using the (default) > `.set reorder' mode, perhaps forced explicitly in case these macros are > pasted into `.set noreorder' code, to make it easier to avoid subtle data > dependency bugs, and also to make R6 porting easier. Except maybe for the

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 16:34, Borislav Petkov wrote: > On Mon, Dec 05, 2016 at 02:36:07PM +0100, Sebastian Frias wrote: >> + * Equivalent of BIT(x) but for contiguous bitfields >> + * SETBITFIELD(1, 0,0xff) = 0x0003 >> + * SETBITFIELD(3, 0,0xff) = 0x000f >> + * SETBITFIELD(15,8,0xff) = 0xff00 >>

Re: [PATCH] bitops: add equivalent of BIT(x) for bitfields

On 05/12/16 16:34, Borislav Petkov wrote: > On Mon, Dec 05, 2016 at 02:36:07PM +0100, Sebastian Frias wrote: >> + * Equivalent of BIT(x) but for contiguous bitfields >> + * SETBITFIELD(1, 0,0xff) = 0x0003 >> + * SETBITFIELD(3, 0,0xff) = 0x000f >> + * SETBITFIELD(15,8,0xff) = 0xff00 >>

Re: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

On 12/04/2016 05:13 AM, Li, Liang Z wrote: >> On 11/30/2016 12:43 AM, Liang Li wrote: >>> +static void send_unused_pages_info(struct virtio_balloon *vb, >>> + unsigned long req_id) >>> +{ >>> + struct scatterlist sg_in; >>> + unsigned long pos = 0; >>> + struct

Re: [PATCH kernel v5 5/5] virtio-balloon: tell host vm's unused page info

On 12/04/2016 05:13 AM, Li, Liang Z wrote: >> On 11/30/2016 12:43 AM, Liang Li wrote: >>> +static void send_unused_pages_info(struct virtio_balloon *vb, >>> + unsigned long req_id) >>> +{ >>> + struct scatterlist sg_in; >>> + unsigned long pos = 0; >>> + struct

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

On Mon, 5 Dec 2016, Matt Redfearn wrote: > Ah yes, I missed the .set reorder above the EVA ifdef and just included the > .set reorder as the similar snippet here: > http://lxr.free-electrons.com/source/arch/mips/include/asm/stackframe.h#L149 That's a global `.set reorder' for the whole of

Re: [PATCH 3/5] MIPS: Only change $28 to thread_info if coming from user mode

On Mon, 5 Dec 2016, Matt Redfearn wrote: > Ah yes, I missed the .set reorder above the EVA ifdef and just included the > .set reorder as the similar snippet here: > http://lxr.free-electrons.com/source/arch/mips/include/asm/stackframe.h#L149 That's a global `.set reorder' for the whole of

Re: bio linked list corruption.

On Mon, Dec 05, 2016 at 06:09:29PM +0100, Vegard Nossum wrote: > On 5 December 2016 at 12:10, Vegard Nossum wrote: > > On 5 December 2016 at 00:04, Vegard Nossum wrote: > >> FWIW I hit this as well: > >> > >> BUG: unable to handle kernel

Re: bio linked list corruption.

On Mon, Dec 05, 2016 at 06:09:29PM +0100, Vegard Nossum wrote: > On 5 December 2016 at 12:10, Vegard Nossum wrote: > > On 5 December 2016 at 00:04, Vegard Nossum wrote: > >> FWIW I hit this as well: > >> > >> BUG: unable to handle kernel paging request at 81ff08b7 > >> IP: []

Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'

From: Nicolas Pitre Date: Mon, 5 Dec 2016 10:44:32 -0500 (EST) > On Sat, 3 Dec 2016, David Miller wrote: > >> From: Arnd Bergmann >> Date: Sat, 3 Dec 2016 00:04:32 +0100 >> >> > ptp now depends on the optional POSIX_TIMERS setting and fails to build

Re: [PATCH net-next] liquidio: 'imply' ptp instead of 'select'

From: Nicolas Pitre Date: Mon, 5 Dec 2016 10:44:32 -0500 (EST) > On Sat, 3 Dec 2016, David Miller wrote: > >> From: Arnd Bergmann >> Date: Sat, 3 Dec 2016 00:04:32 +0100 >> >> > ptp now depends on the optional POSIX_TIMERS setting and fails to build >> > if we select it without that: >> >

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On 12/05, Peter Zijlstra wrote: > > > + for (;;) { > > + set_current_state(TASK_UNINTERRUPTIBLE); > > + > > + if (readers_active_check(sem)) > > + break; > > + > > + schedule(); > > + } > > + > > + rcu_assign_pointer(sem->writer, NULL); > > And

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On 12/05, Peter Zijlstra wrote: > > > + for (;;) { > > + set_current_state(TASK_UNINTERRUPTIBLE); > > + > > + if (readers_active_check(sem)) > > + break; > > + > > + schedule(); > > + } > > + > > + rcu_assign_pointer(sem->writer, NULL); > > And

Re: Enabling peer to peer device transactions for PCIe devices

On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote: > Hi All > > This has been a great thread (thanks to Alex for kicking it off) and I > wanted to jump in and maybe try and put some summary around the > discussion. I also wanted to propose we include this as a topic for LFS/MM >

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

Le 05/12/2016 à 17:31, Mika Westerberg a écrit : > On Mon, Dec 05, 2016 at 02:33:12PM +0100, Marek Vasut wrote: >> On 12/05/2016 12:27 PM, Mika Westerberg wrote: >>> On Mon, Nov 28, 2016 at 03:06:23PM +0300, Mika Westerberg wrote: This is 6th iteration of the series. You can find the previous

CVE-2016-7097 causes acl leak

Commit 073931017b49d9458aa351605b43a7e34598caef has several occurrences of an acl leak. posix_acl_update_mode(inose, , ); . . . posix_acl_release(acl); acl is NULLed in posix_acl_update_mode to signal caller to not update the acl; but because it is nulled, it is never released.

Re: Enabling peer to peer device transactions for PCIe devices

On Sun, Dec 04, 2016 at 07:23:00AM -0600, Stephen Bates wrote: > Hi All > > This has been a great thread (thanks to Alex for kicking it off) and I > wanted to jump in and maybe try and put some summary around the > discussion. I also wanted to propose we include this as a topic for LFS/MM >

Re: [PATCH v6 0/3] spi-nor: Add support for Intel SPI serial flash controller

Le 05/12/2016 à 17:31, Mika Westerberg a écrit : > On Mon, Dec 05, 2016 at 02:33:12PM +0100, Marek Vasut wrote: >> On 12/05/2016 12:27 PM, Mika Westerberg wrote: >>> On Mon, Nov 28, 2016 at 03:06:23PM +0300, Mika Westerberg wrote: This is 6th iteration of the series. You can find the previous

CVE-2016-7097 causes acl leak

Commit 073931017b49d9458aa351605b43a7e34598caef has several occurrences of an acl leak. posix_acl_update_mode(inose, , ); . . . posix_acl_release(acl); acl is NULLed in posix_acl_update_mode to signal caller to not update the acl; but because it is nulled, it is never released.

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

From: Nikita Yushchenko Date: Mon, 5 Dec 2016 16:55:04 +0300 > Aieee I was typing too fast today, sorry... > > send separate "fix for the fix", or re-send patch without that silly typo? If the patch hasn't been applied yet, you resend a fixed version of the

Re: [patch net v2] net: fec: fix compile with CONFIG_M5272

From: Nikita Yushchenko Date: Mon, 5 Dec 2016 16:55:04 +0300 > Aieee I was typing too fast today, sorry... > > send separate "fix for the fix", or re-send patch without that silly typo? If the patch hasn't been applied yet, you resend a fixed version of the patch, always.

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On 12/02, Davidlohr Bueso wrote: > > @@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem) >*/ > __this_cpu_dec(*sem->read_count); > > + rcu_read_lock(); > + writer = rcu_dereference(sem->writer); > + > /* Prod writer to recheck readers_active */ >

RE: [PATCH] usb: gadget: udc: atmel: used managed kasprintf

From: Alexandre Belloni > Sent: 02 December 2016 16:19 > On 02/12/2016 at 15:59:57 +, David Laight wrote : > > From: Alexandre Belloni > > > Sent: 01 December 2016 10:27 > > > Use devm_kasprintf instead of simple kasprintf to free the allocated > > > memory > > > when needed. > > > > s/when

Re: [PATCH v2 2/3] locking/percpu-rwsem: Rework writer block/wake to not use wait-queues

On 12/02, Davidlohr Bueso wrote: > > @@ -102,8 +103,13 @@ void __percpu_up_read(struct percpu_rw_semaphore *sem) >*/ > __this_cpu_dec(*sem->read_count); > > + rcu_read_lock(); > + writer = rcu_dereference(sem->writer); > + > /* Prod writer to recheck readers_active */ >

RE: [PATCH] usb: gadget: udc: atmel: used managed kasprintf

From: Alexandre Belloni > Sent: 02 December 2016 16:19 > On 02/12/2016 at 15:59:57 +, David Laight wrote : > > From: Alexandre Belloni > > > Sent: 01 December 2016 10:27 > > > Use devm_kasprintf instead of simple kasprintf to free the allocated > > > memory > > > when needed. > > > > s/when

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