Re: [PATCH] iio/adc/ltc2497: Driver for Linear Technology LTC2497 ADC

On 23.03.2017 12:28, Peter Meerwald-Stadler wrote: On Thu, 23 Mar 2017, michael.henner...@analog.com wrote: From: Michael Hennerich comments below Hi Peter, Thanks for the review - comments inline. Signed-off-by: Michael Hennerich

Re: [PATCH] iio/adc/ltc2497: Driver for Linear Technology LTC2497 ADC

On 23.03.2017 12:28, Peter Meerwald-Stadler wrote: On Thu, 23 Mar 2017, michael.henner...@analog.com wrote: From: Michael Hennerich comments below Hi Peter, Thanks for the review - comments inline. Signed-off-by: Michael Hennerich --- .../devicetree/bindings/iio/adc/ltc2497.txt

Reply my email please!!!

-- I apologize if this email violates your privacy. It is important and urgent. One Mr Edgar Davies who won huge amount in our recent draw is seriously ill has few weeks to live so his wife and only daughter became so devastated and they told us that they were not interested in the money

Reply my email please!!!

-- I apologize if this email violates your privacy. It is important and urgent. One Mr Edgar Davies who won huge amount in our recent draw is seriously ill has few weeks to live so his wife and only daughter became so devastated and they told us that they were not interested in the money

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> Hello, >> >> I've got the following report while running syzkaller fuzzer on >> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected >> kmalloc failure,

Re: [v1 0/9] Early boot time stamps for x86

Hi Thomas, Thank you very much for looking at this patchset. Comments below: On 03/23/2017 06:56 AM, Thomas Gleixner wrote: On Wed, 22 Mar 2017, Pasha Tatashin wrote: Yes, I am certain it is 0 or near 0 on reset on this machine. Because, I Emphasis on "this machine' It's not guaranteed

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern wrote: > On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > >> Hello, >> >> I've got the following report while running syzkaller fuzzer on >> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected >> kmalloc failure, most likely it's the root

Re: [v1 0/9] Early boot time stamps for x86

Hi Thomas, Thank you very much for looking at this patchset. Comments below: On 03/23/2017 06:56 AM, Thomas Gleixner wrote: On Wed, 22 Mar 2017, Pasha Tatashin wrote: Yes, I am certain it is 0 or near 0 on reset on this machine. Because, I Emphasis on "this machine' It's not guaranteed

Re: [PATCH v2 5/7] clk: tegra: don't warn for PLL defaults unnecessarily

erting this on top of -next allows the board to boot again. I have not had chance to dig into this any further yet, but can unless you have some thoughts. Cheers Jon [0] https://nvtb.github.io//linux-next/test_next-20170323/20170323021534/boot/tegra210-smaug/tegra210-smaug/defconfig_log.txt -- nvpublic

Re: [PATCH v2 5/7] clk: tegra: don't warn for PLL defaults unnecessarily

ws the board to boot again. I have not had chance to dig into this any further yet, but can unless you have some thoughts. Cheers Jon [0] https://nvtb.github.io//linux-next/test_next-20170323/20170323021534/boot/tegra210-smaug/tegra210-smaug/defconfig_log.txt -- nvpublic

[PATCH 0/6 v5] [GIT PULL] ftrace/x86: Ftrace cleanup and add support for -mfentry on x86_32

[ Ingo, Thomas or H.Peter, I believe this is all set to go now. I updated those patches that Linus commented on and I don't believe there are any more issues. I ran this through several tests (although some of my tests are failing due to bugs introduced by others in 4.11-rc2). You can take

[PATCH 6/6 v5] ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o

From: "Steven Rostedt (VMware)" Currently ftrace_32.S and ftrace_64.S are compiled even when CONFIG_FUNCTION_TRACER is not set. This means there's an unnecessary #ifdef to protect the code. Instead of using preprocessor directives, only compile those files when

[PATCH 0/6 v5] [GIT PULL] ftrace/x86: Ftrace cleanup and add support for -mfentry on x86_32

[ Ingo, Thomas or H.Peter, I believe this is all set to go now. I updated those patches that Linus commented on and I don't believe there are any more issues. I ran this through several tests (although some of my tests are failing due to bugs introduced by others in 4.11-rc2). You can take

[PATCH 6/6 v5] ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o

From: "Steven Rostedt (VMware)" Currently ftrace_32.S and ftrace_64.S are compiled even when CONFIG_FUNCTION_TRACER is not set. This means there's an unnecessary #ifdef to protect the code. Instead of using preprocessor directives, only compile those files when FUNCTION_TRACER is defined. Link:

[PATCH 1/6 v5] ftrace/x86_64: Rename mcount_64.S to ftrace_64.S

From: "Steven Rostedt (VMware)" With the advent of -mfentry that uses the new "fentry" hook over mcount, the mcount name is obsolete. Having the code file that ftrace hooks into called "mcount*.S" is rather misleading. Rename it to ftrace_64.S Signed-off-by: Steven Rostedt

[PATCH 1/6 v5] ftrace/x86_64: Rename mcount_64.S to ftrace_64.S

From: "Steven Rostedt (VMware)" With the advent of -mfentry that uses the new "fentry" hook over mcount, the mcount name is obsolete. Having the code file that ftrace hooks into called "mcount*.S" is rather misleading. Rename it to ftrace_64.S Signed-off-by: Steven Rostedt (VMware) ---

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

Hi Dong, Am Freitag, den 24.03.2017, 14:24 +0800 schrieb Dong Aisheng: [...] > > +static struct platform_driver imx7_pgc_domain_driver = { > > + .driver = { > > + .name = "imx7-pgc", > > + }, > > + .probe= imx7_pgc_domain_probe, > > + .remove = imx7_pgc_domain_remove, > >

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

Hi Dong, Am Freitag, den 24.03.2017, 14:24 +0800 schrieb Dong Aisheng: [...] > > +static struct platform_driver imx7_pgc_domain_driver = { > > + .driver = { > > + .name = "imx7-pgc", > > + }, > > + .probe= imx7_pgc_domain_probe, > > + .remove = imx7_pgc_domain_remove, > >

[PATCH 2/6 v5] ftrace/x86_32: Move the ftrace specific code out of entry_32.S

From: "Steven Rostedt (VMware)" The function tracing hook code for ftrace is not an entry point from userspace and does not belong in the entry_*.S files. It has already been moved out of entry_64.S. This moves it out of entry_32.S into its own ftrace_32.S file. Also

Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver

On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote: > Add DT bindings for power domain driver for GPCv2 IP block found in > i.MX7 SoCs. > > Cc: yurov...@gmail.com > Cc: Lucas Stach > Cc: Rob Herring > Cc: Mark Rutland

[PATCH 5/6 v5] ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set

From: "Steven Rostedt (VMware)" x86_64 has had fentry support for some time. I did not add support to x86_32 as I was unsure if it will be used much in the future. It is still very much used, and there's issues with function graph tracing with gcc playing around with the

[PATCH 2/6 v5] ftrace/x86_32: Move the ftrace specific code out of entry_32.S

From: "Steven Rostedt (VMware)" The function tracing hook code for ftrace is not an entry point from userspace and does not belong in the entry_*.S files. It has already been moved out of entry_64.S. This moves it out of entry_32.S into its own ftrace_32.S file. Also updated the comment in

Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver

On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote: > Add DT bindings for power domain driver for GPCv2 IP block found in > i.MX7 SoCs. > > Cc: yurov...@gmail.com > Cc: Lucas Stach > Cc: Rob Herring > Cc: Mark Rutland > Cc: Fabio Estevam > Cc: Dong Aisheng > Cc:

[PATCH 5/6 v5] ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set

From: "Steven Rostedt (VMware)" x86_64 has had fentry support for some time. I did not add support to x86_32 as I was unsure if it will be used much in the future. It is still very much used, and there's issues with function graph tracing with gcc playing around with the mcount frames, causing

[PATCH 4/6 v5] ftrace/x86_32: Clean up ftrace_regs_caller

From: "Steven Rostedt (VMware)" When ftrace_regs_caller was created, it was designed to preserve flags as much as possible as it needed to act just like a breakpoint triggered on the same location. But the design is over complicated as it treated all operations as modifying

[PATCH 3/6 v5] ftrace/x86_32: Add stack frame pointer to ftrace_caller

From: "Steven Rostedt (VMware)" The function hook ftrace_caller does not create its own stack frame, and this causes the ftrace stack trace to miss the first function when doing stack traces. # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter Before:

[PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

No caller currently checks the return value of kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on freeing their device. A stale reference will remain in the io_bus, getting at least used again, when the iobus gets teared down on kvm_destroy_vm() - leading to use after free

[PATCH 4/6 v5] ftrace/x86_32: Clean up ftrace_regs_caller

From: "Steven Rostedt (VMware)" When ftrace_regs_caller was created, it was designed to preserve flags as much as possible as it needed to act just like a breakpoint triggered on the same location. But the design is over complicated as it treated all operations as modifying flags. But push, mov

[PATCH 3/6 v5] ftrace/x86_32: Add stack frame pointer to ftrace_caller

From: "Steven Rostedt (VMware)" The function hook ftrace_caller does not create its own stack frame, and this causes the ftrace stack trace to miss the first function when doing stack traces. # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter Before: -0 [002] .N..

[PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

No caller currently checks the return value of kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on freeing their device. A stale reference will remain in the io_bus, getting at least used again, when the iobus gets teared down on kvm_destroy_vm() - leading to use after free

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected > kmalloc failure, most likely it's the root cause. I find this bug report puzzling. Maybe I don't

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > Hello, > > I've got the following report while running syzkaller fuzzer on > 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected > kmalloc failure, most likely it's the root cause. I find this bug report puzzling. Maybe I don't

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: > From: "Jonathan (Zhixiong) Zhang" > > If ACPI_APEI and MEMORY_FAILURE is configured, select > ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery > when such memory failure is reported through ACPI APEI. APEI

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

Hi Punit, On 01/02/17 21:38, Tyler Baicar wrote: > From: "Jonathan (Zhixiong) Zhang" > > If ACPI_APEI and MEMORY_FAILURE is configured, select > ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery > when such memory failure is reported through ACPI APEI. APEI > (ACPI Platform Error

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 2017-03-23 15:25, John Crispin wrote: > > > On 23/03/17 15:09, Felix Fietkau wrote: >> On 2017-03-23 09:06, Sean Wang wrote: >>> Hi Andrew, >>> >>> The purpose for the regmap table registered is to >>> >>> provide a way which helps us to look up a specific >>> >>> register on the switch

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 2017-03-23 15:25, John Crispin wrote: > > > On 23/03/17 15:09, Felix Fietkau wrote: >> On 2017-03-23 09:06, Sean Wang wrote: >>> Hi Andrew, >>> >>> The purpose for the regmap table registered is to >>> >>> provide a way which helps us to look up a specific >>> >>> register on the switch

[PATCH v2] Add initial SX3000b platform code to MIPS arch

Add support for interrupt controller unit. Use cpu_wait instead of endless loop in cpu_halt. Make coding style changes and documentation additions to platform configuration options. Signed-off-by: Amit Kama arch/mips/Kconfig | 29

[PATCH v2] Add initial SX3000b platform code to MIPS arch

Add support for interrupt controller unit. Use cpu_wait instead of endless loop in cpu_halt. Make coding style changes and documentation additions to platform configuration options. Signed-off-by: Amit Kama arch/mips/Kconfig | 29

Re: [PATCHv3 1/2] mfd: cpcap: implement irq sense helper

On Tue, 21 Mar 2017, Sebastian Reichel wrote: > CPCAP can sense if IRQ is currently set or not. This > functionality is required for a few subdevices, such > as the power button and usb phy modules. > > Acked-by: Tony Lindgren > Signed-off-by: Sebastian Reichel

Re: [PATCHv3 1/2] mfd: cpcap: implement irq sense helper

On Tue, 21 Mar 2017, Sebastian Reichel wrote: > CPCAP can sense if IRQ is currently set or not. This > functionality is required for a few subdevices, such > as the power button and usb phy modules. > > Acked-by: Tony Lindgren > Signed-off-by: Sebastian Reichel > --- > Changes since PATCHv2: >

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Christian, - Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? - Should we restore PCI configuration if amdgpu will be unloaded? - In function amdgpu_resize_bar0(): If resizing for "max" size failed

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Christian, - Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? - Should we restore PCI configuration if amdgpu will be unloaded? - In function amdgpu_resize_bar0(): If resizing for "max" size failed

[PATCH 18/17] x86: Use generic pci_mmap_resource_range()

From: David Woodhouse Signed-off-by: David Woodhouse --- Actually it turns out this is fairly trivial for x86 too; it just looked more interesting at first glance. But pgprot_writecombine() and pgprot_device() will both do the right thing here, and allowing

[PATCH 18/17] x86: Use generic pci_mmap_resource_range()

From: David Woodhouse Signed-off-by: David Woodhouse --- Actually it turns out this is fairly trivial for x86 too; it just looked more interesting at first glance. But pgprot_writecombine() and pgprot_device() will both do the right thing here, and allowing WC conditionally based on

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

On Tue, Mar 21, 2017 at 07:50:04AM -0700, Andrey Smirnov wrote: > Add code allowing for control of various power domains managed by GPCv2 > IP block found in i.MX7 series of SoCs. Power domains covered by this > patch are: > > - PCIE PHY > - MIPI PHY > - USB HSIC PHY > - USB

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

On Tue, Mar 21, 2017 at 07:50:04AM -0700, Andrey Smirnov wrote: > Add code allowing for control of various power domains managed by GPCv2 > IP block found in i.MX7 series of SoCs. Power domains covered by this > patch are: > > - PCIE PHY > - MIPI PHY > - USB HSIC PHY > - USB

Please I want you to patiently read this offer.?

Hello. I know this means of communication may not be morally right to you as a person but I also have had a great thought about it and I have come to this conclusion which I am about to share with you. INTRODUCTION:I am the Credit Manager U. B. A Bank of Burkina Faso Ouagadougou and in one way

Please I want you to patiently read this offer.?

Hello. I know this means of communication may not be morally right to you as a person but I also have had a great thought about it and I have come to this conclusion which I am about to share with you. INTRODUCTION:I am the Credit Manager U. B. A Bank of Burkina Faso Ouagadougou and in one way

Re: [PATCH v2 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller

Hi Geert, thanks for detailed review On Wed, Mar 22, 2017 at 11:26:58AM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add combined gpio and pin controller driver for Renesas RZ/A1 > > r7s72100 SoC. > >

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 14:56, wrote: > On 23/03/17 14:37, Jan Beulich wrote: > On 23.03.17 at 13:52, wrote: >>> Connecting to the backend isn't working reliably in xen-fbfront: in >>> case XenbusStateInitWait of the backend has been missed the backend >>>

Re: [PATCH v2 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller

Hi Geert, thanks for detailed review On Wed, Mar 22, 2017 at 11:26:58AM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi > wrote: > > Add combined gpio and pin controller driver for Renesas RZ/A1 > > r7s72100 SoC. > > > > Signed-off-by: Jacopo

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

>>> On 23.03.17 at 14:56, wrote: > On 23/03/17 14:37, Jan Beulich wrote: > On 23.03.17 at 13:52, wrote: >>> Connecting to the backend isn't working reliably in xen-fbfront: in >>> case XenbusStateInitWait of the backend has been missed the backend >>> transition to XenbusStateConnected will

[PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

From: Michael Hennerich This patch adds support for the Analog Devices / Linear Technology LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches. The LTC4306 optionally provides two general purpose input/output pins (GPIOs) that can be configured as logic

[PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

From: Michael Hennerich This patch adds support for the Analog Devices / Linear Technology LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches. The LTC4306 optionally provides two general purpose input/output pins (GPIOs) that can be configured as logic inputs, opendrain outputs or

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 23/03/17 15:09, Felix Fietkau wrote: On 2017-03-23 09:06, Sean Wang wrote: Hi Andrew, The purpose for the regmap table registered is to provide a way which helps us to look up a specific register on the switch through regmap-debugfs. And not all ranges of register is defined so I

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 23/03/17 15:09, Felix Fietkau wrote: On 2017-03-23 09:06, Sean Wang wrote: Hi Andrew, The purpose for the regmap table registered is to provide a way which helps us to look up a specific register on the switch through regmap-debugfs. And not all ranges of register is defined so I

Re: Purpose of PCI address in ranges property

On Thu, Mar 23, 2017 at 3:59 AM, valmiki wrote: > On 3/20/2017 3:15 AM, Arnd Bergmann wrote: >> >> On Sun, Mar 19, 2017 at 3:14 PM, valmiki wrote: >>> >>> Hi, >>> >>> When ranges property is being parsed using >>> of_pci_get_host_bridge_resources, >>>

Re: Purpose of PCI address in ranges property

On Thu, Mar 23, 2017 at 3:59 AM, valmiki wrote: > On 3/20/2017 3:15 AM, Arnd Bergmann wrote: >> >> On Sun, Mar 19, 2017 at 3:14 PM, valmiki wrote: >>> >>> Hi, >>> >>> When ranges property is being parsed using >>> of_pci_get_host_bridge_resources, >>> the pci address is being used for >>>

Re: fs: use-after-free in path_lookupat

On Sun, Mar 5, 2017 at 8:18 PM, Al Viro wrote: > On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote: > >> Added more debug output. >> >> name_to_handle_at(r4, &(0x7f003000-0x6)="2e2f62757300", >> &(0x7f003000-0xd)={0xc, 0x0, "cd21"},

Re: fs: use-after-free in path_lookupat

On Sun, Mar 5, 2017 at 8:18 PM, Al Viro wrote: > On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote: > >> Added more debug output. >> >> name_to_handle_at(r4, &(0x7f003000-0x6)="2e2f62757300", >> &(0x7f003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f002000)=0x0, >> 0x1000) >> >>

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 23/03/17 13:05, Mason wrote: > I think this version is ready for review. > It has all the required bits and pieces. > I still have a few questions, embedded as comments in the code. > (Missing are ancillary changes to Kconfig, Makefile) May I suggest that if you think that a patch is ready for

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On Fri, Feb 24, 2017 at 05:39:08PM -0800, Stephen Boyd wrote: > Quoting James Morse (2017-02-20 03:10:10) > > On 17/02/17 15:53, Stephen Boyd wrote: > > > Quoting James Morse (2017-02-17 03:00:39) > > >> On 17/02/17 01:19, Stephen Boyd wrote: > > >>> diff --git a/arch/arm64/mm/fault.c

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > > > On 2017年03月23日 08:30, Laura Abbott wrote: >> Hi, >> >> Fedora has received multiple reports of crashes when running >> 4.11 as a guest >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1430297 >>

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

On 23/03/17 13:05, Mason wrote: > I think this version is ready for review. > It has all the required bits and pieces. > I still have a few questions, embedded as comments in the code. > (Missing are ancillary changes to Kconfig, Makefile) May I suggest that if you think that a patch is ready for

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

Hi Stephen, On Fri, Feb 24, 2017 at 05:39:08PM -0800, Stephen Boyd wrote: > Quoting James Morse (2017-02-20 03:10:10) > > On 17/02/17 15:53, Stephen Boyd wrote: > > > Quoting James Morse (2017-02-17 03:00:39) > > >> On 17/02/17 01:19, Stephen Boyd wrote: > > >>> diff --git a/arch/arm64/mm/fault.c

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote: > > > On 2017年03月23日 08:30, Laura Abbott wrote: >> Hi, >> >> Fedora has received multiple reports of crashes when running >> 4.11 as a guest >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1430297 >>

Re: [PATCH] qedf: fix wrong le16 conversion

Arnd Bergmann writes: > gcc points out that we are converting a 16-bit integer into a 32-bit > little-endian type and assigning that to 16-bit little-endian > will end up with a zero: > > drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function > 'init_initiator_rw_fcoe_task': >

Re: [PATCH] qedf: fix wrong le16 conversion

Arnd Bergmann writes: > gcc points out that we are converting a 16-bit integer into a 32-bit > little-endian type and assigning that to 16-bit little-endian > will end up with a zero: > > drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function > 'init_initiator_rw_fcoe_task': >

Re: [PATCH] xen, fbfront: fix connecting to backend

On 03/23/2017 08:52 AM, Juergen Gross wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions required

Re: [PATCH] xen, fbfront: fix connecting to backend

On 03/23/2017 08:52 AM, Juergen Gross wrote: > Connecting to the backend isn't working reliably in xen-fbfront: in > case XenbusStateInitWait of the backend has been missed the backend > transition to XenbusStateConnected will trigger the connected state > only without doing the actions required

fs: GPF in deactivate_locked_super

Hello, I've got the following crash while running syzkaller on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 4874

fs: GPF in deactivate_locked_super

Hello, I've got the following crash while running syzkaller on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 PID: 4874

Re: [PATCH] xen, fbfront: add support for specifying size via xenstore

On 03/23/2017 08:53 AM, Juergen Gross wrote: > Today xen-fbfront supports specifying the display size via module > parameters only. Add support for specifying the size via Xenstore in > order to enable doing this easily via the domain's Xen configuration. > > Add an error message in case the

Re: [PATCH] xen, fbfront: add support for specifying size via xenstore

On 03/23/2017 08:53 AM, Juergen Gross wrote: > Today xen-fbfront supports specifying the display size via module > parameters only. Add support for specifying the size via Xenstore in > order to enable doing this easily via the domain's Xen configuration. > > Add an error message in case the

lib, fs, cgroup: WARNING in percpu_ref_kill_and_confirm

Hello, The following program triggers WARNING in percpu_ref_kill_and_confirm: https://gist.githubusercontent.com/dvyukov/bcfcef3d6b24b9fd841b88ee20c14d4b/raw/a54aeeb09ad1e0659b0ed87ef5efc4480ab2536f/gistfile1.txt [ cut here ] WARNING: CPU: 3 PID: 19987 at

lib, fs, cgroup: WARNING in percpu_ref_kill_and_confirm

Hello, The following program triggers WARNING in percpu_ref_kill_and_confirm: https://gist.githubusercontent.com/dvyukov/bcfcef3d6b24b9fd841b88ee20c14d4b/raw/a54aeeb09ad1e0659b0ed87ef5efc4480ab2536f/gistfile1.txt [ cut here ] WARNING: CPU: 3 PID: 19987 at

loop: WARNING in sysfs_remove_group

Hello, I've got the following WARNING while running syzkaller on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 3 PID:

loop: WARNING in sysfs_remove_group

Hello, I've got the following WARNING while running syzkaller on 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected kmalloc failure, most likely it's the root cause. FAULT_INJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 0 CPU: 3 PID:

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 2017-03-23 09:06, Sean Wang wrote: > Hi Andrew, > > The purpose for the regmap table registered is to > > provide a way which helps us to look up a specific > > register on the switch through regmap-debugfs. > > > And not all ranges of register is defined > > so I only include the

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

On 2017-03-23 09:06, Sean Wang wrote: > Hi Andrew, > > The purpose for the regmap table registered is to > > provide a way which helps us to look up a specific > > register on the switch through regmap-debugfs. > > > And not all ranges of register is defined > > so I only include the

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, 23 Mar 2017 19:36:51 +0900 Byungchul Park wrote: > On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote: > > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > > It would be better to avoid pushing tasks to other cpu within > > > a

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, 23 Mar 2017 19:36:51 +0900 Byungchul Park wrote: > On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote: > > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > > It would be better to avoid pushing tasks to other cpu within > > > a SD_PREFER_SIBLING domain,

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

> - if (!cpu_has_vmx_vpid()) > + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() || > + !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global())) I still don't like this way of indentation, but looks like I am the only one complaining :) So I think this patch is

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

> - if (!cpu_has_vmx_vpid()) > + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() || > + !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global())) I still don't like this way of indentation, but looks like I am the only one complaining :) So I think this patch is

Re: [PATCH v3] refcount: add refcount_t API kernel-doc comments

On Thu, Mar 23, 2017 at 12:40 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> On Fri, Mar 10, 2017 at 7:34 AM, David Windsor wrote: >> > v3: rebase against latest Linus tree; re-add include/linux/refcount.h >> > missing from v2

Re: [PATCH v3] refcount: add refcount_t API kernel-doc comments

On Thu, Mar 23, 2017 at 12:40 AM, Ingo Molnar wrote: > > * Kees Cook wrote: > >> On Fri, Mar 10, 2017 at 7:34 AM, David Windsor wrote: >> > v3: rebase against latest Linus tree; re-add include/linux/refcount.h >> > missing from v2 series >> > >> > Signed-off-by: David Windsor >> >>

[PATCH] sched/completions: use true/false for bool returns

tested with: x86_64_defconfig Patch is against 4.11-rc3 (localversion-next is next-20170323) kernel/sched/completion.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c index 53f9558..ef92b15 100644 --- a/

[PATCH] sched/completions: use true/false for bool returns

with: x86_64_defconfig Patch is against 4.11-rc3 (localversion-next is next-20170323) kernel/sched/completion.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c index 53f9558..ef92b15 100644 --- a/kernel/sched/completion.c

[PATCH V2] hangcheck-timer: Fix typo in comment

Correct patch for the typo. Sorry for I sent first patch w/o commit log and second patch with incorrect fix. Thanks! Fix the typo "alloted" -> "allotted" in comment. Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH V2] hangcheck-timer: Fix typo in comment

Correct patch for the typo. Sorry for I sent first patch w/o commit log and second patch with incorrect fix. Thanks! Fix the typo "alloted" -> "allotted" in comment. Signed-off-by: Shile Zhang --- drivers/char/hangcheck-timer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote: > Hi Michel, > > On 23 March 2017 at 08:53, Michel Dänzer wrote: > > Otherwise this can also prevent modesets e.g. for switching VTs, when > > multiple monitors with different native resolutions are connected. > >

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote: > Hi Michel, > > On 23 March 2017 at 08:53, Michel Dänzer wrote: > > Otherwise this can also prevent modesets e.g. for switching VTs, when > > multiple monitors with different native resolutions are connected. > > > > The depths must

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, 23 Mar 2017 18:21:23 +0900 Byungchul Park wrote: > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > It would be better to avoid pushing tasks to other cpu within > > a SD_PREFER_SIBLING domain, instead, get more chances to check other > >

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

On Thu, 23 Mar 2017 18:21:23 +0900 Byungchul Park wrote: > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote: > > It would be better to avoid pushing tasks to other cpu within > > a SD_PREFER_SIBLING domain, instead, get more chances to check other > > siblings. > > +cc

Re: [PATCH 15/15] i2c-cht-wc: Add Intel Cherry Trail Whiskey Cove SMBUS controller driver

Hi, On 17-03-17 19:22, Andy Shevchenko wrote: On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote: The Intel Cherry Trail Whiskey Cove PMIC has a builtin SMBUS controller for talking to an external PMIC. Add a driver for this. Looking to all this mess we have with PMICs, perhaps some file

Re: [PATCH 15/15] i2c-cht-wc: Add Intel Cherry Trail Whiskey Cove SMBUS controller driver

Hi, On 17-03-17 19:22, Andy Shevchenko wrote: On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote: The Intel Cherry Trail Whiskey Cove PMIC has a builtin SMBUS controller for talking to an external PMIC. Add a driver for this. Looking to all this mess we have with PMICs, perhaps some file

Re: [PATCH v3 0/5] ATA/ARM: convert ARM/DaVinci to use libata PATA drivers

On Wednesday 22 March 2017 11:50 PM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patchset adds Palmchip BK3710 IDE controller driver to > libata and switches ARM/DaVinci to use it (instead of the old > IDE driver). > > Sekhar, please check that it still works after changes, thanks. Did some

Re: perf_callchain_user oops

On Thu, Mar 23, 2017 at 10:40:22AM +0100, Peter Zijlstra wrote: > On Wed, Mar 22, 2017 at 10:58:04PM -0400, Dave Jones wrote: > > Not seen this one before.. > > > > Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > That's a write fault reaching no_context() afaict. > > > CPU: 1 PID: 24420

Re: [PATCH v3 0/5] ATA/ARM: convert ARM/DaVinci to use libata PATA drivers

On Wednesday 22 March 2017 11:50 PM, Bartlomiej Zolnierkiewicz wrote: > Hi, > > This patchset adds Palmchip BK3710 IDE controller driver to > libata and switches ARM/DaVinci to use it (instead of the old > IDE driver). > > Sekhar, please check that it still works after changes, thanks. Did some

Re: perf_callchain_user oops

On Thu, Mar 23, 2017 at 10:40:22AM +0100, Peter Zijlstra wrote: > On Wed, Mar 22, 2017 at 10:58:04PM -0400, Dave Jones wrote: > > Not seen this one before.. > > > > Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC > > That's a write fault reaching no_context() afaict. > > > CPU: 1 PID: 24420

<    8   9   10   11   12   13   14   15   16   17   >