Re: [PATCH] efi: ARM: avoid warning about phys_addr_t cast

On Mon, 18 Apr, at 10:34:19AM, Arnd Bergmann wrote: > memblock_remove() takes a phys_addr_t, which may be narrower than 64 bits, > causing a harmless warning: > > drivers/firmware/efi/arm-init.c: In function 'reserve_regions': > include/linux/kernel.h:29:20: error: large integer implicitly

Re: [PATCH] efi: ARM: avoid warning about phys_addr_t cast

On Mon, 18 Apr, at 10:34:19AM, Arnd Bergmann wrote: > memblock_remove() takes a phys_addr_t, which may be narrower than 64 bits, > causing a harmless warning: > > drivers/firmware/efi/arm-init.c: In function 'reserve_regions': > include/linux/kernel.h:29:20: error: large integer implicitly

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 12.04.2016 13:09, Tejun Heo wrote: >> >> Probably you want to look into: >> https://lkml.org/lkml/2016/3/10/21 >> >> The patch mentioned above solves the issue for me. > > Heh, I tracked it down to wb_over_bg_thresh() and fell asleep. Yeah, > that is the right fix. Works wonderfully now,

Re: [fuse-devel] Horrible mmap write performance (kernel writeback issue?)

On 12.04.2016 13:09, Tejun Heo wrote: >> >> Probably you want to look into: >> https://lkml.org/lkml/2016/3/10/21 >> >> The patch mentioned above solves the issue for me. > > Heh, I tracked it down to wb_over_bg_thresh() and fell asleep. Yeah, > that is the right fix. Works wonderfully now,

Re: [PATCH v2 4/4] drivers: staging: remove BUG_ON

On 04/17/2016 05:35 PM, Tobin C Harding wrote: drivers/staging/android/ion/ion.c calls BUG_ON in places where WARN_ON will suffice. This patch replaces two such occurences. Two other occurences remain. You got the logic flow correct but I'd prefer to keep the BUG_ON. It's catching actual

Re: [PATCH v2 4/4] drivers: staging: remove BUG_ON

On 04/17/2016 05:35 PM, Tobin C Harding wrote: drivers/staging/android/ion/ion.c calls BUG_ON in places where WARN_ON will suffice. This patch replaces two such occurences. Two other occurences remain. You got the logic flow correct but I'd prefer to keep the BUG_ON. It's catching actual

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

On Thursday 07 April 2016 14:00:36 Viresh Kumar wrote: > On 01-04-16, 09:15, Rob Herring wrote: > > On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar > > wrote: > > > > > > > > > And the cpufreq-dt driver can match /cpus node's compatible string against > > >

Re: [PATCH V1 Resend 2/3] cpufreq: dt: Add generic platform-device creation support

On Thursday 07 April 2016 14:00:36 Viresh Kumar wrote: > On 01-04-16, 09:15, Rob Herring wrote: > > On Fri, Apr 1, 2016 at 5:23 AM, Viresh Kumar > > wrote: > > > > > > > > > And the cpufreq-dt driver can match /cpus node's compatible string against > > > "operating-points-v2" and create a

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

On 2016-04-18 17:11, Mark Brown wrote: > On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote: >> Mark Brown wrote: > >>> >>> There aren't any (beyond the usual references to the Wolfson datasheets >>> which I'd suggest should be in here) but that doesn't mean we should >>> ignore this

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

On 2016-04-18 17:11, Mark Brown wrote: > On Mon, Apr 18, 2016 at 01:18:47PM +, Peter Rosin wrote: >> Mark Brown wrote: > >>> >>> There aren't any (beyond the usual references to the Wolfson datasheets >>> which I'd suggest should be in here) but that doesn't mean we should >>> ignore this

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 18 Apr 2016 12:51:43 -0700 Alexei Starovoitov wrote: > yeah, it could be added to ftrace as well, but it won't be as effective > as perf_trace, since the cost of trace_event_buffer_reserve() in > trace_event_raw_event_() handler is significantly higher than >

Re: [PATCH v3 1/2] dax: add dax_get_unmapped_area for pmd mappings

On Thu 14-04-16 10:48:30, Toshi Kani wrote: > + > +/** > + * dax_get_unmapped_area - handle get_unmapped_area for a DAX file > + * @filp: The file being mmap'd, if not NULL > + * @addr: The mmap address. If NULL, the kernel assigns the address > + * @len: The mmap size in bytes > + * @pgoff: The

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On Mon, 18 Apr 2016 12:51:43 -0700 Alexei Starovoitov wrote: > yeah, it could be added to ftrace as well, but it won't be as effective > as perf_trace, since the cost of trace_event_buffer_reserve() in > trace_event_raw_event_() handler is significantly higher than > perf_trace_buf_alloc() in

Re: [PATCH v3 1/2] dax: add dax_get_unmapped_area for pmd mappings

On Thu 14-04-16 10:48:30, Toshi Kani wrote: > + > +/** > + * dax_get_unmapped_area - handle get_unmapped_area for a DAX file > + * @filp: The file being mmap'd, if not NULL > + * @addr: The mmap address. If NULL, the kernel assigns the address > + * @len: The mmap size in bytes > + * @pgoff: The

Re: [PATCH 13/15] parallel lookups machinery, part 3

On Sat, Apr 16, 2016 at 01:55:25AM +0100, Al Viro wrote: > From: Al Viro > > We will need to be able to check if there is an in-lookup > dentry with matching parent/name. Right now it's impossible, > but as soon as start locking directories shared such beasts > will

Re: [PATCH 13/15] parallel lookups machinery, part 3

On Sat, Apr 16, 2016 at 01:55:25AM +0100, Al Viro wrote: > From: Al Viro > > We will need to be able to check if there is an in-lookup > dentry with matching parent/name. Right now it's impossible, > but as soon as start locking directories shared such beasts > will appear. > > Add a secondary

Re: [PART1 RFC v4 02/11] KVM: x86: Introducing kvm_x86_ops VM init/uninit hooks

Radim, On 04/12/2016 03:49 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Adding function pointers in struct kvm_x86_ops for processor-specific layer to provide hooks for when KVM initialize and un-initialize VM. Signed-off-by: Suravee Suthikulpanit

Re: [PART1 RFC v4 02/11] KVM: x86: Introducing kvm_x86_ops VM init/uninit hooks

Radim, On 04/12/2016 03:49 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Adding function pointers in struct kvm_x86_ops for processor-specific layer to provide hooks for when KVM initialize and un-initialize VM. Signed-off-by: Suravee Suthikulpanit --- diff --git

Клиентские базы тел +79133913837 Skype: prodawez389 Email: ammanakuw-7...@yopmail.com тел +79133913837

Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса. По базе можно звонить, писать, слать факсы и email, вести любые прямые активные продажи Ваших товаров и услуг Узнайте подробнее по тел +79133913837 (whatsapp,viber,telegram) Skype: prodawez389 Email:

Клиентские базы тел +79133913837 Skype: prodawez389 Email: ammanakuw-7...@yopmail.com тел +79133913837

Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего Бизнеса. По базе можно звонить, писать, слать факсы и email, вести любые прямые активные продажи Ваших товаров и услуг Узнайте подробнее по тел +79133913837 (whatsapp,viber,telegram) Skype: prodawez389 Email:

[PATCH v3 0/2] drm: introduce bus_flags for pixel clock polarity

Hi, Dropped the first patch in version 3 since that is already applied in v4.6. Also moved all generic changes (including the changes in panel-simple) to the first, generic patch. Instead of using struct drm_display_mode to convey the pixel clock polarity information, this patchset introduces a

[PATCH v3 1/2] drm: introduce bus_flags in drm_display_info

Introduce bus_flags to specify display bus properties like signal polarities. This is useful for parallel display buses, e.g. to specify the pixel clock or data enable polarity. Suggested-by: Thierry Reding Acked-by: Philipp Zabel Acked-by:

[PATCH v3 0/2] drm: introduce bus_flags for pixel clock polarity

Hi, Dropped the first patch in version 3 since that is already applied in v4.6. Also moved all generic changes (including the changes in panel-simple) to the first, generic patch. Instead of using struct drm_display_mode to convey the pixel clock polarity information, this patchset introduces a

[PATCH v3 1/2] drm: introduce bus_flags in drm_display_info

Introduce bus_flags to specify display bus properties like signal polarities. This is useful for parallel display buses, e.g. to specify the pixel clock or data enable polarity. Suggested-by: Thierry Reding Acked-by: Philipp Zabel Acked-by: Manfred Schlaegl Signed-off-by: Stefan Agner ---

[PATCH v3 2/2] drm/fsl-dcu: use bus_flags for pixel clock polarity

The drivers current default configuration drives the pixel data on rising edge of the pixel clock. However, most display sample data on rising edge... This leads to color shift artefacts visible especially at edges. This patch changes the relevant defines to be useful and actually set the bits,

[PATCH v3 2/2] drm/fsl-dcu: use bus_flags for pixel clock polarity

The drivers current default configuration drives the pixel data on rising edge of the pixel clock. However, most display sample data on rising edge... This leads to color shift artefacts visible especially at edges. This patch changes the relevant defines to be useful and actually set the bits,

Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation

On Mon, Apr 18, 2016 at 06:31:26PM +0900, SeongJae Park wrote: > Well, looks like there is neither strong positive opinion nor strong negative > opinion. So, I will post the patch again with the suggested workflow soon. Makes sense to me! Let's see how things look after a few months.

Re: [PATCH memory-barriers.txt 6/7] documentation: Add Korean translation

On Mon, Apr 18, 2016 at 06:31:26PM +0900, SeongJae Park wrote: > Well, looks like there is neither strong positive opinion nor strong negative > opinion. So, I will post the patch again with the suggested workflow soon. Makes sense to me! Let's see how things look after a few months.

Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

On Mon, 4 Apr 2016 21:52:48 -0700 Alexei Starovoitov wrote: > introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be > attached to tracepoints. > The tracepoint will copy the arguments in the per-cpu buffer and pass > it to the bpf program as its first argument. > The

Re: [PART1 RFC v4 01/11] KVM: x86: Misc LAPIC changes to expose helper functions

On 04/19/2016 02:57 AM, Suravee Suthikulpanit wrote: Radim, On 04/12/2016 03:34 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Exporting LAPIC utility functions and macros for re-use in SVM code. Signed-off-by: Suravee Suthikulpanit

Re: [PATCH 1/2] localmodconfig: Fix parsing of Kconfig "source" statements

On 2016/04/10 16:52, Benjamin Poirier wrote: > On 2016/04/08 14:29, Steven Rostedt wrote: > > On Sat, 2 Apr 2016 10:55:21 -0700 > > Benjamin Poirier wrote: > > > > > The parameter of Kconfig "source" statements does not need to be quoted. > > > The current regex causes many

Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints

On Mon, 4 Apr 2016 21:52:48 -0700 Alexei Starovoitov wrote: > introduce BPF_PROG_TYPE_TRACEPOINT program type and allow it to be > attached to tracepoints. > The tracepoint will copy the arguments in the per-cpu buffer and pass > it to the bpf program as its first argument. > The layout of the

Re: [PART1 RFC v4 01/11] KVM: x86: Misc LAPIC changes to expose helper functions

On 04/19/2016 02:57 AM, Suravee Suthikulpanit wrote: Radim, On 04/12/2016 03:34 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Exporting LAPIC utility functions and macros for re-use in SVM code. Signed-off-by: Suravee Suthikulpanit --- Adding kvm_lapic_set_reg

Re: [PATCH 1/2] localmodconfig: Fix parsing of Kconfig "source" statements

On 2016/04/10 16:52, Benjamin Poirier wrote: > On 2016/04/08 14:29, Steven Rostedt wrote: > > On Sat, 2 Apr 2016 10:55:21 -0700 > > Benjamin Poirier wrote: > > > > > The parameter of Kconfig "source" statements does not need to be quoted. > > > The current regex causes many kconfig files to be

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Fri 15-04-16 22:05:31, Andrew Morton wrote: > On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > size. This feature relies on both mmap virtual address and FS > > block (i.e. physical address)

Re: [PATCH v3 0/2] Align mmap address for DAX pmd mappings

On Fri 15-04-16 22:05:31, Andrew Morton wrote: > On Thu, 14 Apr 2016 10:48:29 -0600 Toshi Kani wrote: > > > When CONFIG_FS_DAX_PMD is set, DAX supports mmap() using pmd page > > size. This feature relies on both mmap virtual address and FS > > block (i.e. physical address) to be aligned by the

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

On 04/18/2016 03:06 PM, Borislav Petkov wrote: On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote: the number of uncorrectable errors is useful from a system point of view. I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want to do that even for UEs

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

On 04/18/2016 03:06 PM, Borislav Petkov wrote: On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote: the number of uncorrectable errors is useful from a system point of view. I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want to do that even for UEs

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If

Greetings!!!

Hi, how are you? My name is J Eric Denials, External Financial Auditor at Lloyds Banking Group plc., London. It is a pleasure to contact you at this time through this medium. I have a cool and legitimate deal to do with you as you're a foreigner, it will be mutually beneficial to both. If

Re: [PATCH 2/2] console: Add ioctl for flushing the scrollback buffer

Hi Manuel, [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.6-rc4 next-20160418] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Manuel-Sch-lling/Persistent-scrollback

Re: [PATCH 2/2] console: Add ioctl for flushing the scrollback buffer

Hi Manuel, [auto build test ERROR on usb/usb-testing] [also build test ERROR on v4.6-rc4 next-20160418] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Manuel-Sch-lling/Persistent-scrollback

Re: [PATCH 2/8] writeback: add wbc_to_write_cmd()

On 04/18/2016 11:12 AM, Jan Kara wrote: On Sun 17-04-16 23:24:41, Jens Axboe wrote: Add wbc_to_write_cmd(), which returns the write type to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type.

Re: [PATCH 2/8] writeback: add wbc_to_write_cmd()

On 04/18/2016 11:12 AM, Jan Kara wrote: On Sun 17-04-16 23:24:41, Jens Axboe wrote: Add wbc_to_write_cmd(), which returns the write type to use, based on a struct writeback_control. No functional changes in this patch, but it prepares us for factoring other wbc fields for write type.

Re: [PATCH v2] tty: msm_serial: remove static clk rate setting in probe

On Mon, Mar 07, 2016 at 02:46:40AM +, Srinivas Kandagatla wrote: > The issue with setting up a fixed clock rate at probe is that it would > overwrite the console rate set by the bootloader for its console device. > This would result in serial out corruption or missing log when we system > is

Re: [PATCH v2] tty: msm_serial: remove static clk rate setting in probe

On Mon, Mar 07, 2016 at 02:46:40AM +, Srinivas Kandagatla wrote: > The issue with setting up a fixed clock rate at probe is that it would > overwrite the console rate set by the bootloader for its console device. > This would result in serial out corruption or missing log when we system > is

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Mon, Apr 18, 2016 at 10:04:43PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 20:43:36 Pablo Neira Ayuso wrote: > > On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > > > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > > > On Sat, Apr 16, 2016 at 10:17:43PM

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Mon, Apr 18, 2016 at 10:04:43PM +0200, Arnd Bergmann wrote: > On Monday 18 April 2016 20:43:36 Pablo Neira Ayuso wrote: > > On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > > > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > > > On Sat, Apr 16, 2016 at 10:17:43PM

Re: [PATCH -tip 2/3] locking/pvqspinlock: Avoid double resetting of stats

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: ... remove the redundant second iteration, this is most likely a copy/past buglet. Signed-off-by: Davidlohr Bueso --- kernel/locking/qspinlock_stat.h | 2 -- 1 file changed, 2 deletions(-) diff --git

Re: [PATCH -tip 2/3] locking/pvqspinlock: Avoid double resetting of stats

On 04/18/2016 02:31 AM, Davidlohr Bueso wrote: ... remove the redundant second iteration, this is most likely a copy/past buglet. Signed-off-by: Davidlohr Bueso --- kernel/locking/qspinlock_stat.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/kernel/locking/qspinlock_stat.h

[PATCH net-next] net: dsa: kill circular reference with slave priv

The dsa_slave_priv structure does not need a pointer to its net_device. Kill it. Signed-off-by: Vivien Didelot --- net/dsa/dsa_priv.h | 5 - net/dsa/slave.c| 9 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git

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

On 04/18/2016 03:02 PM, Borislav Petkov wrote: On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? Yes, you are correct. I'd still get the single bit correction by

[PATCH net-next] net: dsa: kill circular reference with slave priv

The dsa_slave_priv structure does not need a pointer to its net_device. Kill it. Signed-off-by: Vivien Didelot --- net/dsa/dsa_priv.h | 5 - net/dsa/slave.c| 9 - 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h index

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

On 04/18/2016 03:02 PM, Borislav Petkov wrote: On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? Yes, you are correct. I'd still get the single bit correction by

Re: [PATCH] tty: serial: msm: Support more bauds

On Fri, Mar 25, 2016 at 02:35:49PM -0700, Stephen Boyd wrote: > Fixes: 850b37a71bde ("tty: serial: msm: Remove 115.2 Kbps maximum baud rate > limitation") > Cc: "Ivan T. Ivanov" > Cc: Srinivas Kandagatla > Cc: Andy Gross

Re: [PATCH] tty: serial: msm: Support more bauds

On Fri, Mar 25, 2016 at 02:35:49PM -0700, Stephen Boyd wrote: > Fixes: 850b37a71bde ("tty: serial: msm: Remove 115.2 Kbps maximum baud rate > limitation") > Cc: "Ivan T. Ivanov" > Cc: Srinivas Kandagatla > Cc: Andy Gross > Cc: Matthew McClintock > Signed-off-by: Stephen Boyd Acked-by:

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Rob, [...] >> +Required properties for MCB subnode: >> +- compatible : Shall be "apm,xgene-pmu-mcb". >> +- reg: First resource shall be the MCB PMU resource. >> +- index : Instance number of the MCB PMU. >> + >> +Required properties for MC

Re: [PATCH v2 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

Hi Rob, [...] >> +Required properties for MCB subnode: >> +- compatible : Shall be "apm,xgene-pmu-mcb". >> +- reg: First resource shall be the MCB PMU resource. >> +- index : Instance number of the MCB PMU. >> + >> +Required properties for MC

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

On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote: > > the number of uncorrectable errors is useful from a system point of > > view. I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want to do that even for UEs coming from the network...? Seems a bit

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

On Mon, Apr 18, 2016 at 10:02:27PM +0200, Borislav Petkov wrote: > > the number of uncorrectable errors is useful from a system point of > > view. I forgot: so altr_edac_a10_ecc_irq() panics on uncorrectable errors. Do we want to do that even for UEs coming from the network...? Seems a bit

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Monday 18 April 2016 20:43:36 Pablo Neira Ayuso wrote: > On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > > > A recent patch removed many 'inline'

Re: [PATCH] netfilter: ctnetlink: add more #ifdef around unused code

On Monday 18 April 2016 20:43:36 Pablo Neira Ayuso wrote: > On Mon, Apr 18, 2016 at 08:33:15PM +0200, Arnd Bergmann wrote: > > On Monday 18 April 2016 20:16:59 Pablo Neira Ayuso wrote: > > > On Sat, Apr 16, 2016 at 10:17:43PM +0200, Arnd Bergmann wrote: > > > > A recent patch removed many 'inline'

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

On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: > We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? > which makes the entire system more stable and the ability to see both > single bit errors corrected and the number of

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

On Mon, Apr 18, 2016 at 09:27:16AM -0500, Thor Thayer wrote: > We're still getting the single bit correction By that you mean, you get that by enabling ECC on the FIFO block? > which makes the entire system more stable and the ability to see both > single bit errors corrected and the number of

Re: [PATCH RFC 3/3] vfio: add virtio pci quirk

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization

Re: [PATCH RFC 3/3] vfio: add virtio pci quirk

On Mon, 18 Apr 2016 12:58:28 +0300 "Michael S. Tsirkin" wrote: > Modern virtio pci devices can set VIRTIO_F_IOMMU_PLATFORM > to signal they are safe to use with an IOMMU. > > Without this bit, exposing the device to userspace is unsafe, so probe > and fail VFIO initialization unless noiommu is

[PATCH 1/2] console: Add persistent scrollback buffers for all VGA consoles

Add a scrollback buffers for each VGA console. The benefit is that the scrollback history is not flushed when switching between consoles but is persistent. The buffers are allocated on demand when a new console is opened. This breaks tools like clear_console that rely on flushing the scrollback

[PATCH 2/2] console: Add ioctl for flushing the scrollback buffer

Tools like clear_console rely on the fact that scrollback history is flushed when switching back and forth between consoles. Persistent scrollback buffers for each console breaks this, so this patch adds a ioctl() callf for flushing the scrollback history. Signed-off-by: Manuel Schölling

[PATCH 1/2] console: Add persistent scrollback buffers for all VGA consoles

Add a scrollback buffers for each VGA console. The benefit is that the scrollback history is not flushed when switching between consoles but is persistent. The buffers are allocated on demand when a new console is opened. This breaks tools like clear_console that rely on flushing the scrollback

[PATCH 2/2] console: Add ioctl for flushing the scrollback buffer

Tools like clear_console rely on the fact that scrollback history is flushed when switching back and forth between consoles. Persistent scrollback buffers for each console breaks this, so this patch adds a ioctl() callf for flushing the scrollback history. Signed-off-by: Manuel Schölling ---

[PATCH 0/2] Persistent scrollback buffers for all VGA consoles

Another attempt to add persistent scrollback buffers for all VGA consoles, so the buffer is not flushed when swithing back and forth between consoles. Note that breaks tools like bash's clear_console and thus might have security implications: clear_console relies on this 'anti-feature' of the

Re: [PART1 RFC v4 01/11] KVM: x86: Misc LAPIC changes to expose helper functions

Radim, On 04/12/2016 03:34 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Exporting LAPIC utility functions and macros for re-use in SVM code. Signed-off-by: Suravee Suthikulpanit --- Adding kvm_lapic_set_reg looks weird when KVM has

[PATCH 0/2] Persistent scrollback buffers for all VGA consoles

Another attempt to add persistent scrollback buffers for all VGA consoles, so the buffer is not flushed when swithing back and forth between consoles. Note that breaks tools like bash's clear_console and thus might have security implications: clear_console relies on this 'anti-feature' of the

Re: [PART1 RFC v4 01/11] KVM: x86: Misc LAPIC changes to expose helper functions

Radim, On 04/12/2016 03:34 AM, Radim Krčmář wrote: 2016-04-07 03:20-0500, Suravee Suthikulpanit: Exporting LAPIC utility functions and macros for re-use in SVM code. Signed-off-by: Suravee Suthikulpanit --- Adding kvm_lapic_set_reg looks weird when KVM has kvm_apic_get_reg, but the

[PATCH 1/5] input: twl6040-vibra: fix DT node memory management

commit e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") made the separate vibra DT node to a subnode of the twl6040. It now calls of_find_node_by_name() to locate the "vibra" subnode. This function has a side effect to call of_node_put on() for the twl6040 parent node

[PATCH 1/5] input: twl6040-vibra: fix DT node memory management

commit e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") made the separate vibra DT node to a subnode of the twl6040. It now calls of_find_node_by_name() to locate the "vibra" subnode. This function has a side effect to call of_node_put on() for the twl6040 parent node

[PATCH 2/5] input: twl6040-vibra: add handler to unregister input if module is removed

commit 1f9e1470ab34 ("Input: twl6040-vibra - use devm functions") converted everything to devm but we still need to call input_unregister_device(info->input_dev) Solution: add back twl6040_vibra_remove to call input_unregister_device Signed-off-by: H. Nikolaus Schaller ---

[PATCH 0/2] Persistent scrollback buffers for all VGA consoles

Another attempt to add persistent scrollback buffers for all VGA consoles, so the buffer is not flushed when swithing back and forth between consoles. Note that breaks tools like bash's clear_console and thus might have security implications: clear_console relies on this 'anti-feature' of the

[PATCH 5/5] input: twl6040-vibra: remove mutex

The mutex does not seem to be needed. twl4030-vibra doesn't use one either. Signed-off-by: H. Nikolaus Schaller --- drivers/input/misc/twl6040-vibra.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/input/misc/twl6040-vibra.c

[PATCH 2/5] input: twl6040-vibra: add handler to unregister input if module is removed

commit 1f9e1470ab34 ("Input: twl6040-vibra - use devm functions") converted everything to devm but we still need to call input_unregister_device(info->input_dev) Solution: add back twl6040_vibra_remove to call input_unregister_device Signed-off-by: H. Nikolaus Schaller ---

[PATCH 0/2] Persistent scrollback buffers for all VGA consoles

Another attempt to add persistent scrollback buffers for all VGA consoles, so the buffer is not flushed when swithing back and forth between consoles. Note that breaks tools like bash's clear_console and thus might have security implications: clear_console relies on this 'anti-feature' of the

[PATCH 5/5] input: twl6040-vibra: remove mutex

The mutex does not seem to be needed. twl4030-vibra doesn't use one either. Signed-off-by: H. Nikolaus Schaller --- drivers/input/misc/twl6040-vibra.c | 15 +-- 1 file changed, 1 insertion(+), 14 deletions(-) diff --git a/drivers/input/misc/twl6040-vibra.c

[PATCH 4/5] input: twl6040-vibra: ignore return value of schedule_work

returning ret is wrong. And checking for an error as well. User space may call multiple times until the work is really scheduled. twl4030-vibra.c also ignores the return value. Signed-off-by: H. Nikolaus Schaller --- drivers/input/misc/twl6040-vibra.c | 6 +- 1 file

[PATCH 4/5] input: twl6040-vibra: ignore return value of schedule_work

returning ret is wrong. And checking for an error as well. User space may call multiple times until the work is really scheduled. twl4030-vibra.c also ignores the return value. Signed-off-by: H. Nikolaus Schaller --- drivers/input/misc/twl6040-vibra.c | 6 +- 1 file changed, 1

[PATCH 0/5] fixes for twl6040-vibra

There are some small bugs in the twl6040-vibra driver and differences to how twl4030 vibra works. This patch series addresses them. H. Nikolaus Schaller (5): input: twl6040-vibra: fix DT node memory management input: twl6040-vibra: add handler to unregister input if module is removed

[PATCH 0/5] fixes for twl6040-vibra

There are some small bugs in the twl6040-vibra driver and differences to how twl4030 vibra works. This patch series addresses them. H. Nikolaus Schaller (5): input: twl6040-vibra: fix DT node memory management input: twl6040-vibra: add handler to unregister input if module is removed

[PATCH 3/5] input: twl6040-vibra: fix NULL pointer dereference by removing workqueue

commit 21fb9f0d5e91 ("Input: twl6040-vibra - use system workqueue") says that it switches to use the system workqueue but it did neither - remove the workqueue struct variable - replace code to really use the system workqueue Instead it calls queue_work() on uninitialized info->workqueue. The

[PATCH 3/5] input: twl6040-vibra: fix NULL pointer dereference by removing workqueue

commit 21fb9f0d5e91 ("Input: twl6040-vibra - use system workqueue") says that it switches to use the system workqueue but it did neither - remove the workqueue struct variable - replace code to really use the system workqueue Instead it calls queue_work() on uninitialized info->workqueue. The

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On 4/18/16 9:13 AM, Steven Rostedt wrote: On Mon, 4 Apr 2016 21:52:46 -0700 Alexei Starovoitov wrote: Hi Steven, Peter, last time we discussed bpf+tracepoints it was a year ago [1] and the reason we didn't proceed with that approach was that bpf would make arguments arg1, arg2

Re: [PATCH net-next 0/8] allow bpf attach to tracepoints

On 4/18/16 9:13 AM, Steven Rostedt wrote: On Mon, 4 Apr 2016 21:52:46 -0700 Alexei Starovoitov wrote: Hi Steven, Peter, last time we discussed bpf+tracepoints it was a year ago [1] and the reason we didn't proceed with that approach was that bpf would make arguments arg1, arg2 to

Re: [PATCH] mm: SLAB freelist randomization

I agree, if we had a generic way to pass entropy across boots on all architecture that would be amazing. I will let the SLAB maintainers to decide on requiring CONFIG_ARCH_RANDOM or documenting it. On Mon, Apr 18, 2016 at 12:36 PM, Laura Abbott wrote: > On 04/18/2016 08:59

Re: [PATCH] mm: SLAB freelist randomization

I agree, if we had a generic way to pass entropy across boots on all architecture that would be amazing. I will let the SLAB maintainers to decide on requiring CONFIG_ARCH_RANDOM or documenting it. On Mon, Apr 18, 2016 at 12:36 PM, Laura Abbott wrote: > On 04/18/2016 08:59 AM, Thomas Garnier

Re: [RFC] iio: st: Add lsm9ds0 support for gyro accel and magny

On 18/04/16 11:25, Crestez Dan Leonard wrote: > On 04/18/2016 09:07 AM, Denis Ciocca wrote: >> Hi Leonard and Jonathan, >> >> basically the patch can not work. > Well, it can work as long as you don't initialize both the accel and the > magn at the same time. There is no issue with the gyro

Re: [RFC] iio: st: Add lsm9ds0 support for gyro accel and magny

On 18/04/16 11:25, Crestez Dan Leonard wrote: > On 04/18/2016 09:07 AM, Denis Ciocca wrote: >> Hi Leonard and Jonathan, >> >> basically the patch can not work. > Well, it can work as long as you don't initialize both the accel and the > magn at the same time. There is no issue with the gyro

[PATCH] hwmon: (ads7828) Enable internal reference

On ads7828 the internal reference defaults to off upon power up. When using internal reference, it needs to be turned on and the voltage needs to settle before normal conversion cycle can be started. Hence perform a dummy read in the probe to enable the internal reference allowing the voltage to

[PATCH] hwmon: (ads7828) Enable internal reference

On ads7828 the internal reference defaults to off upon power up. When using internal reference, it needs to be turned on and the voltage needs to settle before normal conversion cycle can be started. Hence perform a dummy read in the probe to enable the internal reference allowing the voltage to

Re: [PATCH v3 1/2] ext4: Pass in DIO_SKIP_DIO_COUNT flag if inode_dio_begin() called

On 04/15/2016 06:19 PM, Dave Chinner wrote: On Fri, Apr 15, 2016 at 01:17:41PM -0400, Waiman Long wrote: On 04/15/2016 04:17 AM, Dave Chinner wrote: On Thu, Apr 14, 2016 at 12:21:13PM -0400, Waiman Long wrote: What the patch does is to eliminate the innermost inode_dio_begin/end pair. Yes,

Re: [4.4-rc1][Regression] drm/i915: Check live status before reading edid

On 03/28/2016 02:39 PM, Joseph Salisbury wrote: > On 03/02/2016 04:58 PM, Joseph Salisbury wrote: >> On 02/29/2016 04:33 AM, Jani Nikula wrote: >>> On Wed, 24 Feb 2016, Joseph Salisbury >>> wrote: Hi Sonika, A kernel bug report was opened against

Re: [PATCH v3 1/2] ext4: Pass in DIO_SKIP_DIO_COUNT flag if inode_dio_begin() called

On 04/15/2016 06:19 PM, Dave Chinner wrote: On Fri, Apr 15, 2016 at 01:17:41PM -0400, Waiman Long wrote: On 04/15/2016 04:17 AM, Dave Chinner wrote: On Thu, Apr 14, 2016 at 12:21:13PM -0400, Waiman Long wrote: What the patch does is to eliminate the innermost inode_dio_begin/end pair. Yes,

Re: [4.4-rc1][Regression] drm/i915: Check live status before reading edid

On 03/28/2016 02:39 PM, Joseph Salisbury wrote: > On 03/02/2016 04:58 PM, Joseph Salisbury wrote: >> On 02/29/2016 04:33 AM, Jani Nikula wrote: >>> On Wed, 24 Feb 2016, Joseph Salisbury >>> wrote: Hi Sonika, A kernel bug report was opened against Ubuntu [0]. After a kernel

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