Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD

> Ksenija Stanojevic hat am 2. November 2016 um > 08:38 geschrieben: > > > Add core files for low resolution analog-to-digital converter (mxs-lradc) > MFD driver. > > Signed-off-by: Ksenija Stanojevic Tested-by: Stefan Wahren

Re: [PATCH v9 1/5] mfd: mxs-lradc: Add support for mxs-lradc MFD

> Ksenija Stanojevic hat am 2. November 2016 um > 08:38 geschrieben: > > > Add core files for low resolution analog-to-digital converter (mxs-lradc) > MFD driver. > > Signed-off-by: Ksenija Stanojevic Tested-by: Stefan Wahren for Patch 1 + 2 > --- > ... > diff --git a/drivers/mfd/Makefile

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

On 11/07, Rajendra Nayak wrote: > > > On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote: > > Well I'm also curious which case is failing. Does turning on the > > clocks work after the gdsc is enabled? Does turning off the > > clocks fail because we don't know when the gdsc has turned off? I > > would

Re: [PATCH 3/3] clk: qcom: Set BRANCH_HALT_DELAY flags for venus core0/1 clks

On 11/07, Rajendra Nayak wrote: > > > On 11/05/2016 01:48 AM, 'Stephen Boyd' wrote: > > Well I'm also curious which case is failing. Does turning on the > > clocks work after the gdsc is enabled? Does turning off the > > clocks fail because we don't know when the gdsc has turned off? I > > would

Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity

On Tue, Nov 08, 2016 at 03:25:27PM -0600, Bjorn Helgaas wrote: > What tree would you prefer? I vote for the IRQ tree since that seems > to be where the interesting parts are, and I think I acked all the PCI > bits. Yes, that would be my preference to. > > > + * struct irq_affinity -

Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity

On Tue, Nov 08, 2016 at 03:25:27PM -0600, Bjorn Helgaas wrote: > What tree would you prefer? I vote for the IRQ tree since that seems > to be where the interesting parts are, and I think I acked all the PCI > bits. Yes, that would be my preference to. > > > + * struct irq_affinity -

Re: [PATCH v3 00/11] pwm: imx: Provide atomic operation for IMX PWM driver

Dear All, > This patch set brings atomic operation to i.MX's PWMv2 driver. Are there any more comments regarding this patch set? Best regards, Łukasz Majewski > > This work has been supported and suggested by Boris Brezillon [1] and > Stefan Agner, by showing how simple the transition could

Re: [PATCH v3 00/11] pwm: imx: Provide atomic operation for IMX PWM driver

Dear All, > This patch set brings atomic operation to i.MX's PWMv2 driver. Are there any more comments regarding this patch set? Best regards, Łukasz Majewski > > This work has been supported and suggested by Boris Brezillon [1] and > Stefan Agner, by showing how simple the transition could

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote: > Arnd Bergmann writes: > > > The new pxa2xx_determine_rate() function seems lacking in a few > > regards: > > > > - For an exact match or no match at all, the rate is uninitialized > > as reported by gcc

Re: [PATCH 2/2] clk: pxa: fix pxa2xx_determine_rate return

On Tuesday, November 8, 2016 7:01:57 PM CET Robert Jarzmik wrote: > Arnd Bergmann writes: > > > The new pxa2xx_determine_rate() function seems lacking in a few > > regards: > > > > - For an exact match or no match at all, the rate is uninitialized > > as reported by gcc -Wmaybe-unintialized: >

Re: linux-next: build failure after merge of the rtc tree

Hi, On 08/11/2016 at 17:41:52 +1100, Stephen Rothwell wrote : > Hi Alexandre, > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > > Caused by commit > > f9eb69d1ae2f ("rtc: jz4740: Add support for acting as the system power > controller")

Re: linux-next: build failure after merge of the rtc tree

Hi, On 08/11/2016 at 17:41:52 +1100, Stephen Rothwell wrote : > Hi Alexandre, > > After merging the rtc tree, today's linux-next build (x86_64 allmodconfig) > failed like this: > > > Caused by commit > > f9eb69d1ae2f ("rtc: jz4740: Add support for acting as the system power > controller")

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 2016-11-08 19:38, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Peter Rosin wrote: >> On 2016-11-08 16:59, Thomas Gleixner wrote: > >>> So you need that whole dance including the delayed work because you cannot >>> call iio_write_channel_raw() from hard interrupt context, right? >> >> It's not

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 2016-11-08 19:38, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Peter Rosin wrote: >> On 2016-11-08 16:59, Thomas Gleixner wrote: > >>> So you need that whole dance including the delayed work because you cannot >>> call iio_write_channel_raw() from hard interrupt context, right? >> >> It's not

Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote: > Hi Luis > > > On 2016-10-06 19:37, Luis R. Rodriguez wrote: > > On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote: > > > This patch uses recently introduced device links to track the runtime pm > > > state of the

Re: [PATCH v4 2/2] iommu/exynos: Add proper runtime pm support

On Mon, Oct 10, 2016 at 03:32:06PM +0200, Marek Szyprowski wrote: > Hi Luis > > > On 2016-10-06 19:37, Luis R. Rodriguez wrote: > > On Thu, Sep 29, 2016 at 10:12:31AM +0200, Marek Szyprowski wrote: > > > This patch uses recently introduced device links to track the runtime pm > > > state of the

Re: [PATCH 1/3] kbuild: add -fno-PIE

On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote: > Debian started to build the gcc with -fPIE by default so the kernel > build ends before it starts properly with: > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode > > Also add to KBUILD_AFLAGS

Re: [PATCH 1/3] kbuild: add -fno-PIE

On Fri, Nov 04, 2016 at 07:39:38PM +0100, Sebastian Andrzej Siewior wrote: > Debian started to build the gcc with -fPIE by default so the kernel > build ends before it starts properly with: > |kernel/bounds.c:1:0: error: code model kernel does not support PIC mode > > Also add to KBUILD_AFLAGS

Re: [PATCH v10 7/7] KVM: x86: virtualize cpuid faulting

On Tue, Nov 8, 2016 at 10:39 AM, Kyle Huey wrote: > Hardware support for faulting on the cpuid instruction is not required to > emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant > MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a >

Re: [PATCH v10 7/7] KVM: x86: virtualize cpuid faulting

On Tue, Nov 8, 2016 at 10:39 AM, Kyle Huey wrote: > Hardware support for faulting on the cpuid instruction is not required to > emulate it, because cpuid triggers a VM exit anyways. KVM handles the relevant > MSRs (MSR_PLATFORM_INFO and MSR_MISC_FEATURES_ENABLE) and upon a > cpuid-induced VM exit

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

Hi Eric, During testing this patch I find a segfault, please see inline comment. In addition, since both the BPF map array and map names should be done after symbol table is collected, merging bpf_object__init_maps and bpf_object__init_maps_name would be a good practice, making code simpler.

Re: [PATCH 7/8] tools lib bpf: fix maps resolution

Hi Eric, During testing this patch I find a segfault, please see inline comment. In addition, since both the BPF map array and map names should be done after symbol table is collected, merging bpf_object__init_maps and bpf_object__init_maps_name would be a good practice, making code simpler.

Re: KASAN & the vmalloc area

On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether

Re: KASAN & the vmalloc area

On Tue, Nov 8, 2016 at 11:03 AM, Mark Rutland wrote: > Hi, > > I see a while back [1] there was a discussion of what to do about KASAN > and vmapped stacks, but it doesn't look like that was solved, judging by > the vmapped stacks pull [2] for v4.9. > > I wondered whether anyone had looked at

[PATCH v5] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Allan Chou Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller (Vendor=04b4 ProdID=3610). Patch verified on x64 linux kernel 4.7.4, 4.8.6, 4.9-rc4 systems with the Kensington SD4600P USB-C Universal Dock with Power, which uses the Cypress GX3

[PATCH v5] Net Driver: Add Cypress GX3 VID=04b4 PID=3610.

From: Allan Chou Add support for Cypress GX3 SuperSpeed to Gigabit Ethernet Bridge Controller (Vendor=04b4 ProdID=3610). Patch verified on x64 linux kernel 4.7.4, 4.8.6, 4.9-rc4 systems with the Kensington SD4600P USB-C Universal Dock with Power, which uses the Cypress GX3 SuperSpeed to Gigabit

Re: [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams

On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote: > Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching > capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly > decryption of an encrypted bitstream. > > If the system is not booted in secure mode AES & HMAC units > are

Re: [PATCH 3/4] fpga mgr: zynq: Add support for encrypted bitstreams

On Sun, 2016-11-06 at 17:13:25 -0700, Moritz Fischer wrote: > Add new flag FPGA_MGR_DECRYPT_BISTREAM as well as a matching > capability FPGA_MGR_CAP_DECRYPT to allow for on-the-fly > decryption of an encrypted bitstream. > > If the system is not booted in secure mode AES & HMAC units > are

[PATCH] tools lib bpf: fix maps resolution

From: Eric Leblond It is not correct to assimilate the elf data of the maps section to an array of map definition. In fact the sizes differ. The offset provided in the symbol section has to be used instead. This patch fixes a bug causing a elf with two maps not to load

[PATCH] tools lib bpf: fix maps resolution

From: Eric Leblond It is not correct to assimilate the elf data of the maps section to an array of map definition. In fact the sizes differ. The offset provided in the symbol section has to be used instead. This patch fixes a bug causing a elf with two maps not to load correctly. Wang Nan

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, 8 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote: > > And yes, you should spend the extra cycles. Adding a flags argument to > > mce_setup() and propagate it through the various callsites shouldn't be > > that hard and would make the

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, 8 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote: > > And yes, you should spend the extra cycles. Adding a flags argument to > > mce_setup() and propagate it through the various callsites shouldn't be > > that hard and would make the

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On Tue, 8 Nov 2016, Peter Rosin wrote: > So, to sum up, in order for this to work with threaded oneshot > interrupts, I still need to either keep the enable/sync/enable-dance > or tweak the irq core to handle my case better. The only gain would > be that I could fire the next step of the search

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On Tue, 8 Nov 2016, Peter Rosin wrote: > So, to sum up, in order for this to work with threaded oneshot > interrupts, I still need to either keep the enable/sync/enable-dance > or tweak the irq core to handle my case better. The only gain would > be that I could fire the next step of the search

[PATCH] MIPS: fix duplicate define

The mips build of ip27_defconfig is failing with the error: In file included from ../arch/mips/include/asm/mach-ip27/spaces.h:29:0, from ../arch/mips/include/asm/page.h:12, from ../arch/mips/vdso/vdso.h:26, from

[PATCH] MIPS: fix duplicate define

The mips build of ip27_defconfig is failing with the error: In file included from ../arch/mips/include/asm/mach-ip27/spaces.h:29:0, from ../arch/mips/include/asm/page.h:12, from ../arch/mips/vdso/vdso.h:26, from

Re: [PATCH v11 13/22] vfio: Introduce common function to add capabilities

On Wed, 9 Nov 2016 02:16:17 +0530 Kirti Wankhede wrote: > On 11/8/2016 12:59 PM, Alexey Kardashevskiy wrote: > > On 05/11/16 08:10, Kirti Wankhede wrote: > >> Vendor driver using mediated device framework should use > >> vfio_info_add_capability() to add capabilities. >

Re: [PATCH v11 13/22] vfio: Introduce common function to add capabilities

On Wed, 9 Nov 2016 02:16:17 +0530 Kirti Wankhede wrote: > On 11/8/2016 12:59 PM, Alexey Kardashevskiy wrote: > > On 05/11/16 08:10, Kirti Wankhede wrote: > >> Vendor driver using mediated device framework should use > >> vfio_info_add_capability() to add capabilities. > >> Introduced this

Re: [PATCH] checkpatch: Fix warnings when --no-tree is used

On Fri, 2016-10-21 at 13:27 -0700, Jeff Kirsher wrote: > When users run checkpatch.pl with --no-tree option, $root is not > defined, which causes an ugly warning that it is not initialized at > line 764.  The test for whether or not a file is maintained should > only be run when a kernel tree is

Re: [PATCH] checkpatch: Fix warnings when --no-tree is used

On Fri, 2016-10-21 at 13:27 -0700, Jeff Kirsher wrote: > When users run checkpatch.pl with --no-tree option, $root is not > defined, which causes an ugly warning that it is not initialized at > line 764.  The test for whether or not a file is maintained should > only be run when a kernel tree is

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

Apologies, just cleaning out old mail and finding some I should have responded to long ago: On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "callback_wq" queues a single work item >cb_work per > nfsd4_callback instance and thus, it doesn't require execution

Re: [PATCH v2] fs/nfsd/nfs4callback: Remove deprecated create_singlethread_workqueue

Apologies, just cleaning out old mail and finding some I should have responded to long ago: On Wed, Aug 31, 2016 at 02:23:48AM +0530, Bhaktipriya Shridhar wrote: > The workqueue "callback_wq" queues a single work item >cb_work per > nfsd4_callback instance and thus, it doesn't require execution

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 2016-11-08 16:59, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Peter Rosin wrote: >> +/* >> + * The envelope_detector_comp_latch function works together with the compare >> + * interrupt service routine below (envelope_detector_comp_isr) as a latch >> + * (one-bit memory) for if the interrupt

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

Em Tue, 8 Nov 2016 22:15:24 +0100 Benjamin Larsson escreveu: > On 11/08/2016 09:22 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 8 Nov 2016 10:42:03 -0800 > > Linus Torvalds escreveu: > > > >> On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte

Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator

On 2016-11-08 16:59, Thomas Gleixner wrote: > On Tue, 8 Nov 2016, Peter Rosin wrote: >> +/* >> + * The envelope_detector_comp_latch function works together with the compare >> + * interrupt service routine below (envelope_detector_comp_isr) as a latch >> + * (one-bit memory) for if the interrupt

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

Em Tue, 8 Nov 2016 22:15:24 +0100 Benjamin Larsson escreveu: > On 11/08/2016 09:22 PM, Mauro Carvalho Chehab wrote: > > Em Tue, 8 Nov 2016 10:42:03 -0800 > > Linus Torvalds escreveu: > > > >> On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote: > >>> Since v4.9-rc4 I get following crash in

Re: [alsa-devel] [PATCH] ASoC: fsl: fix fsl_spdif.c build errors

On Sun, Nov 6, 2016 at 1:40 PM, Randy Dunlap wrote: > On 11/06/16 11:43, Fabio Estevam wrote: >> Hi Randy, >> >> On Sat, Nov 5, 2016 at 9:16 PM, Randy Dunlap wrote: >>> From: Randy Dunlap >>> >>> Fix build errors in

Re: [alsa-devel] [PATCH] ASoC: fsl: fix fsl_spdif.c build errors

On Sun, Nov 6, 2016 at 1:40 PM, Randy Dunlap wrote: > On 11/06/16 11:43, Fabio Estevam wrote: >> Hi Randy, >> >> On Sat, Nov 5, 2016 at 9:16 PM, Randy Dunlap wrote: >>> From: Randy Dunlap >>> >>> Fix build errors in sound/soc/fsl/fsl_spdif.c by selecting BITREVERSE. >>> Fixes these build

[PATCH] proc: optimize render_sigset_t()

render_sigset_t() requires about 30% of time to generate /proc/pid/status. - 74.44% sys_read - 74.40% vfs_read - 74.01% __vfs_read - 73.36% seq_read - 72.97% proc_single_show - 72.26% proc_pid_status + 29.79% render_sigset_t +

[PATCH] proc: optimize render_sigset_t()

render_sigset_t() requires about 30% of time to generate /proc/pid/status. - 74.44% sys_read - 74.40% vfs_read - 74.01% __vfs_read - 73.36% seq_read - 72.97% proc_single_show - 72.26% proc_pid_status + 29.79% render_sigset_t +

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

On 11/08/2016 09:22 PM, Mauro Carvalho Chehab wrote: Em Tue, 8 Nov 2016 10:42:03 -0800 Linus Torvalds escreveu: On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote: Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module. Looks like

Re: [v4.9-rc4] dvb-usb/cinergyT2 NULL pointer dereference

On 11/08/2016 09:22 PM, Mauro Carvalho Chehab wrote: Em Tue, 8 Nov 2016 10:42:03 -0800 Linus Torvalds escreveu: On Sun, Nov 6, 2016 at 7:40 AM, Jörg Otte wrote: Since v4.9-rc4 I get following crash in dvb-usb-cinergyT2 module. Looks like it's commit 5ef8ed0e5608f ("[media] cinergyT2-core:

Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP

On Wed, 9 Nov 2016 01:29:19 +0530 Kirti Wankhede wrote: > On 11/8/2016 11:16 PM, Alex Williamson wrote: > > On Tue, 8 Nov 2016 21:56:29 +0530 > > Kirti Wankhede wrote: > > > >> On 11/8/2016 5:15 AM, Alex Williamson wrote: > >>> On Sat, 5 Nov 2016

Re: [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP

On Wed, 9 Nov 2016 01:29:19 +0530 Kirti Wankhede wrote: > On 11/8/2016 11:16 PM, Alex Williamson wrote: > > On Tue, 8 Nov 2016 21:56:29 +0530 > > Kirti Wankhede wrote: > > > >> On 11/8/2016 5:15 AM, Alex Williamson wrote: > >>> On Sat, 5 Nov 2016 02:40:45 +0530 > >>> Kirti Wankhede wrote:

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

Lars-Peter Clausen writes: > On 10/26/2016 09:41 PM, Robert Jarzmik wrote: >> +#define to_ac97_device(d) container_of(d, struct ac97_codec_device, dev) >> +#define to_ac97_driver(d) container_of(d, struct ac97_codec_driver, driver) > > In my opinion these should be inline

Re: [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus

Lars-Peter Clausen writes: > On 10/26/2016 09:41 PM, Robert Jarzmik wrote: >> +#define to_ac97_device(d) container_of(d, struct ac97_codec_device, dev) >> +#define to_ac97_driver(d) container_of(d, struct ac97_codec_driver, driver) > > In my opinion these should be inline functions rather than

Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity

On Mon, Nov 07, 2016 at 10:47:36AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > Some drivers (various network and RDMA adapter for example) have a MSI-X > vector layout where most of the vectors are used for I/O queues and should > have CPU affinity assigned to

Re: [PATCH 1/7] genirq/affinity: Introduce struct irq_affinity

On Mon, Nov 07, 2016 at 10:47:36AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > Some drivers (various network and RDMA adapter for example) have a MSI-X > vector layout where most of the vectors are used for I/O queues and should > have CPU affinity assigned to them, but some

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote: > And yes, you should spend the extra cycles. Adding a flags argument to > mce_setup() and propagate it through the various callsites shouldn't be > that hard and would make the stuff obvious instead of obfuscated. Sure, that's

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 10:14:04PM +0100, Thomas Gleixner wrote: > And yes, you should spend the extra cycles. Adding a flags argument to > mce_setup() and propagate it through the various callsites shouldn't be > that hard and would make the stuff obvious instead of obfuscated. Sure, that's

Re: [PATCH 3/7] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

On Mon, Nov 07, 2016 at 10:47:38AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > Only calculate the affinity for the main I/O vectors, and skip the > pre or post vectors specified by struct irq_affinity. > > Also remove the irq_affinity cpumask argument that has

Re: [PATCH 3/7] genirq/affinity: Handle pre/post vectors in irq_create_affinity_masks()

On Mon, Nov 07, 2016 at 10:47:38AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > Only calculate the affinity for the main I/O vectors, and skip the > pre or post vectors specified by struct irq_affinity. > > Also remove the irq_affinity cpumask argument that has never been used.

Re: [PATCH 5/7] pci/msi: Provide pci_alloc_irq_vectors_affinity()

On Tue, Nov 08, 2016 at 03:17:32PM -0600, Bjorn Helgaas wrote: > On Mon, Nov 07, 2016 at 10:47:40AM -0800, Christoph Hellwig wrote: > > From: Christogh Hellwig > > s/Christogh/Christoph/ (also below) Haha, so much for taking Thomas' split of my patches and not proof-reading them..

Re: [PATCH 5/7] pci/msi: Provide pci_alloc_irq_vectors_affinity()

On Tue, Nov 08, 2016 at 03:17:32PM -0600, Bjorn Helgaas wrote: > On Mon, Nov 07, 2016 at 10:47:40AM -0800, Christoph Hellwig wrote: > > From: Christogh Hellwig > > s/Christogh/Christoph/ (also below) Haha, so much for taking Thomas' split of my patches and not proof-reading them..

Re: [PATCH 4/7] pci/msi: Propagate irq affinity description through the MSI code

s|pci/msi|PCI/MSI| (subject) s/irq/IRQ/ (subject) On Mon, Nov 07, 2016 at 10:47:39AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > No API change yet, just pass it down all the way from > pci_alloc_irq_vectors to the core MSI code. pci_alloc_irq_vectors() >

Re: [PATCH 4/7] pci/msi: Propagate irq affinity description through the MSI code

s|pci/msi|PCI/MSI| (subject) s/irq/IRQ/ (subject) On Mon, Nov 07, 2016 at 10:47:39AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig > > No API change yet, just pass it down all the way from > pci_alloc_irq_vectors to the core MSI code. pci_alloc_irq_vectors() > Signed-off-by:

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, 8 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote: > > That does not make any sense. Where is m.tsc initialized? I couldn't find > > any place which does, except this and the conditional clear farther down in > > that function. > >

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, 8 Nov 2016, Borislav Petkov wrote: > On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote: > > That does not make any sense. Where is m.tsc initialized? I couldn't find > > any place which does, except this and the conditional clear farther down in > > that function. > >

Re: [PATCH 5/7] pci/msi: Provide pci_alloc_irq_vectors_affinity()

On Mon, Nov 07, 2016 at 10:47:40AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig s/Christogh/Christoph/ (also below) > This is a variant of pci_alloc_irq_vectors() that allows passing a > struct irq_affinity to provide fine-grainded IRQ affinity control.

Re: [PATCH 5/7] pci/msi: Provide pci_alloc_irq_vectors_affinity()

On Mon, Nov 07, 2016 at 10:47:40AM -0800, Christoph Hellwig wrote: > From: Christogh Hellwig s/Christogh/Christoph/ (also below) > This is a variant of pci_alloc_irq_vectors() that allows passing a > struct irq_affinity to provide fine-grainded IRQ affinity control. s/grainded/grained/ > For

Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Tue, 8 Nov 2016 13:06:35 -0800 Andy Lutomirski wrote: > Or you could > embed seccomp_data in a bigger structure. I was thinking about doing just that. But for now, I may just use seccomp_data and when we want to add more, we can do the embedding. -- Steve

Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Tue, 8 Nov 2016 13:06:35 -0800 Andy Lutomirski wrote: > Or you could > embed seccomp_data in a bigger structure. I was thinking about doing just that. But for now, I may just use seccomp_data and when we want to add more, we can do the embedding. -- Steve

Re: [PATCH v11 01/22] vfio: Mediated device Core driver

On 11/8/2016 2:55 PM, Dong Jia Shi wrote: > * Kirti Wankhede [2016-11-05 02:40:35 +0530]: > > Hi Kirti, > > [...] >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig >> index da6e2ce77495..23eced02aaf6 100644 >> --- a/drivers/vfio/Kconfig >> +++

Re: [PATCH v11 01/22] vfio: Mediated device Core driver

On 11/8/2016 2:55 PM, Dong Jia Shi wrote: > * Kirti Wankhede [2016-11-05 02:40:35 +0530]: > > Hi Kirti, > > [...] >> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig >> index da6e2ce77495..23eced02aaf6 100644 >> --- a/drivers/vfio/Kconfig >> +++ b/drivers/vfio/Kconfig >> @@ -48,4

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote: > That does not make any sense. Where is m.tsc initialized? I couldn't find > any place which does, except this and the conditional clear farther down in > that function. mce_gather_info->mce_setup does m->tsc = rdtsc(); And we do

Re: [PATCH] x86/MCE: Remove MCP_TIMESTAMP

On Tue, Nov 08, 2016 at 09:39:02PM +0100, Thomas Gleixner wrote: > That does not make any sense. Where is m.tsc initialized? I couldn't find > any place which does, except this and the conditional clear farther down in > that function. mce_gather_info->mce_setup does m->tsc = rdtsc(); And we do

Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Nov 8, 2016 11:48 AM, "Steven Rostedt" wrote: > > On Tue, 8 Nov 2016 08:20:48 -0800 > Andy Lutomirski wrote: > > > On Tue, Nov 8, 2016 at 8:16 AM, Linus Torvalds > > wrote: > > > So I definitely approve of the change,

Re: [RFC][ATCH 1/3] ptrace: Remove maxargs from task_current_syscall()

On Nov 8, 2016 11:48 AM, "Steven Rostedt" wrote: > > On Tue, 8 Nov 2016 08:20:48 -0800 > Andy Lutomirski wrote: > > > On Tue, Nov 8, 2016 at 8:16 AM, Linus Torvalds > > wrote: > > > So I definitely approve of the change, but I wonder if we should go > > > one step further: > > > > > > On Mon,

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

On Mon, Nov 07, 2016 at 09:23:38AM -0800, Dave Hansen wrote: > On 11/06/2016 07:37 PM, Li, Liang Z wrote: > >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM. > >> On a 1TB system, that's 256 passes through the top-level loop. > >> The bottom-level lists have tens of

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

On Mon, Nov 07, 2016 at 09:23:38AM -0800, Dave Hansen wrote: > On 11/06/2016 07:37 PM, Li, Liang Z wrote: > >> Let's say we do a 32k bitmap that can hold ~1M pages. That's 4GB of RAM. > >> On a 1TB system, that's 256 passes through the top-level loop. > >> The bottom-level lists have tens of

Re: [Linux-ima-devel] [PATCH v6 04/10] ima: maintain memory size needed for serializing the measurement list

On Tue, 2016-11-08 at 22:05 +0200, Dmitry Kasatkin wrote: > On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann > wrote: > > From: Mimi Zohar > > > > In preparation for serializing the binary_runtime_measurements, this patch > > maintains

Re: [Linux-ima-devel] [PATCH v6 04/10] ima: maintain memory size needed for serializing the measurement list

On Tue, 2016-11-08 at 22:05 +0200, Dmitry Kasatkin wrote: > On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann > wrote: > > From: Mimi Zohar > > > > In preparation for serializing the binary_runtime_measurements, this patch > > maintains the amount of memory required. > > > > Changelog v5: >

Re: [PATCH 6/7] pci: Remove the irq_affinity mask from struct pci_dev

s/pci/PCI/ (in subject) On Mon, Nov 07, 2016 at 10:47:41AM -0800, Christoph Hellwig wrote: > This has never been used, and now is totally unreferenced. Nuke it. > > Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas > --- > include/linux/pci.h | 1 -

Re: [PATCH 6/7] pci: Remove the irq_affinity mask from struct pci_dev

s/pci/PCI/ (in subject) On Mon, Nov 07, 2016 at 10:47:41AM -0800, Christoph Hellwig wrote: > This has never been used, and now is totally unreferenced. Nuke it. > > Signed-off-by: Christoph Hellwig Acked-by: Bjorn Helgaas > --- > include/linux/pci.h | 1 - > 1 file changed, 1 deletion(-) >

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 08:43:35PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 08, 2016 at 08:21:04PM +0100, Luis R. Rodriguez wrote: > > On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > > > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > > > We have

Re: [PATCH v5 2/5] driver core: Functional dependencies tracking support

On Tue, Nov 08, 2016 at 08:43:35PM +0100, Greg Kroah-Hartman wrote: > On Tue, Nov 08, 2016 at 08:21:04PM +0100, Luis R. Rodriguez wrote: > > On Tue, Nov 08, 2016 at 07:45:41AM +0100, Greg Kroah-Hartman wrote: > > > On Mon, Nov 07, 2016 at 10:22:50PM +0100, Luis R. Rodriguez wrote: > > > > We have

Re: [RFC] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

+CC MarcZ Hi Marc, I have a question below On 11/04/2016 05:17 AM, Yuriy Kolerov wrote: > Ignore value of interrupt distribution mode for common interrupts in > IDU since setting an affinity using value from Device Tree is deprecated > in ARC. Originially it is done in idu_irq_xlate function

Re: [RFC] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

+CC MarcZ Hi Marc, I have a question below On 11/04/2016 05:17 AM, Yuriy Kolerov wrote: > Ignore value of interrupt distribution mode for common interrupts in > IDU since setting an affinity using value from Device Tree is deprecated > in ARC. Originially it is done in idu_irq_xlate function

[PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Signed-off-by: Peter Rosin --- MAINTAINERS| 1 + sound/soc/Kconfig | 1

[PATCH 2/2] ASoC: axentia: tse850: add ASoC driver for the Axentia TSE-850

The TSE-850 is an FM Transmitter Station Equipment, designed to generate baseband signals for FM, mainly the DARC subcarrier, but other signals are also possible. Signed-off-by: Peter Rosin --- MAINTAINERS| 1 + sound/soc/Kconfig | 1 +

Re: [PATCH v2 23/23] staging: iio: tsl2583: move out of staging

On 08/11/16 10:16, Brian Masney wrote: > Move tsl2580, tsl2581, tsl2583 driver out of staging into mainline. > > Signed-off-by: Brian Masney A few minor bits and bobs inline - might need to push one or two into relevant earlier patches, but was easier to just review the

Re: [PATCH v2 23/23] staging: iio: tsl2583: move out of staging

On 08/11/16 10:16, Brian Masney wrote: > Move tsl2580, tsl2581, tsl2583 driver out of staging into mainline. > > Signed-off-by: Brian Masney A few minor bits and bobs inline - might need to push one or two into relevant earlier patches, but was easier to just review the whole code in here as I'm

RE: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Long Li > Sent: Tuesday, November 8, 2016 8:57 AM > To: Greg KH > Cc: linux-...@vger.kernel.org; Haiyang Zhang ; >

RE: [Resend] [PATCH] pci-hyperv: use kmalloc to allocate hypercall params buffer

> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On > Behalf Of Long Li > Sent: Tuesday, November 8, 2016 8:57 AM > To: Greg KH > Cc: linux-...@vger.kernel.org; Haiyang Zhang ; > linux-kernel@vger.kernel.org; Bjorn Helgaas ; >

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left

Re: [PATCH v3] PM / devfreq: Restart previous governor if new governor fails to start

On 11/08/2016 01:02 AM, Chanwoo Choi wrote: Hi, On 2016년 11월 08일 03:57, Saravana Kannan wrote: On 10/26/2016 05:06 PM, Chanwoo Choi wrote: Hi, On 2016년 10월 27일 04:17, Saravana Kannan wrote: If the new governor fails to start, switch back to old governor so that the devfreq state is not left

Re: [PATCH] PCI: Don't attempt to claim shadow copies of ROM

On Mon, Nov 07, 2016 at 05:51:58PM -0600, Bjorn Helgaas wrote: > If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM > and the device never sees accesses to it and doesn't respond to it. We > don't have to route the shadow range to the PCI device, and the device > doesn't

Re: [PATCH] PCI: Don't attempt to claim shadow copies of ROM

On Mon, Nov 07, 2016 at 05:51:58PM -0600, Bjorn Helgaas wrote: > If we're using a shadow copy of a PCI device ROM, the shadow copy is in RAM > and the device never sees accesses to it and doesn't respond to it. We > don't have to route the shadow range to the PCI device, and the device > doesn't

Re: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list

On Tue, 2016-11-08 at 21:46 +0200, Dmitry Kasatkin wrote: > On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann > wrote: > > From: Mimi Zohar > > > > The TPM PCRs are only reset on a hard reboot. In order to validate a > > TPM's quote

Re: [Linux-ima-devel] [PATCH v6 02/10] ima: on soft reboot, restore the measurement list

On Tue, 2016-11-08 at 21:46 +0200, Dmitry Kasatkin wrote: > On Fri, Oct 21, 2016 at 5:44 AM, Thiago Jung Bauermann > wrote: > > From: Mimi Zohar > > > > The TPM PCRs are only reset on a hard reboot. In order to validate a > > TPM's quote after a soft reboot (eg. kexec -e), the IMA measurement

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