Re: [PATCH 5/7] x86: Use IBRS for firmware update path

On Thu, Jan 04, 2018 at 08:08:55PM +, Woodhouse, David wrote: > On Thu, 2018-01-04 at 21:05 +0100, Greg KH wrote: > > On Thu, Jan 04, 2018 at 09:56:46AM -0800, Tim Chen wrote: > > > > > > From: David Woodhouse > > > > > > We are impervious to the indirect branch prediction attack with > > >

Re: Bluetooth: Prevent stack info leak from the EFS element.

On Tue, Jan 02, 2018 at 12:26:15PM -0800, Guenter Roeck wrote: > On Fri, Dec 08, 2017 at 03:14:47PM +0100, gre...@linuxfoundation.org wrote: > > From: Ben Seri <b...@armis.com> > > > > In the function l2cap_parse_conf_rsp and in the function > > l2cap_pars

Re: Bluetooth: Prevent stack info leak from the EFS element.

On Tue, Jan 02, 2018 at 12:26:15PM -0800, Guenter Roeck wrote: > On Fri, Dec 08, 2017 at 03:14:47PM +0100, gre...@linuxfoundation.org wrote: > > From: Ben Seri > > > > In the function l2cap_parse_conf_rsp and in the function > > l2cap_parse_conf_req the following v

Re: [PATCH V3] PM: In kernel power management domain_pm created for async schedules

On Thu, Jan 04, 2018 at 08:59:00AM +, Vikas Bansal wrote: > Sender : Rafael J. Wysocki > > Date : 2017-12-14 03:56 (GMT+5:30) > > > > > > On Wed, Dec 13, 2017 at 9:46 AM, Vikas Bansal > wrote: > >> > >> Sender : Rafael J. Wysocki

Re: [PATCH V3] PM: In kernel power management domain_pm created for async schedules

On Thu, Jan 04, 2018 at 08:59:00AM +, Vikas Bansal wrote: > Sender : Rafael J. Wysocki > > Date : 2017-12-14 03:56 (GMT+5:30) > > > > > > On Wed, Dec 13, 2017 at 9:46 AM, Vikas Bansal > wrote: > >> > >> Sender : Rafael J. Wysocki > >> Date : 2017-12-06 19:48 (GMT+5:30) > >> > >>> > >>>

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Sat, Dec 23, 2017 at 03:53:57PM +, Ghorai, Sukumar wrote: > >> > included in 4.14-rc1, so something needs to be done in Linus's tree > >> > to resolve this issue, otherwise people will hit this as a > >> > regression when moving to 4.14 or newer. > >> > >> Well, I wouldn't object to

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Sat, Dec 23, 2017 at 03:53:57PM +, Ghorai, Sukumar wrote: > >> > included in 4.14-rc1, so something needs to be done in Linus's tree > >> > to resolve this issue, otherwise people will hit this as a > >> > regression when moving to 4.14 or newer. > >> > >> Well, I wouldn't object to

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Fri, Dec 22, 2017 at 09:37:48AM -0800, Brian Norris wrote: > > included in 4.14-rc1, so something needs to be done in Linus's tree to > > resolve this issue, otherwise people will hit this as a regression when > > moving to 4.14 or newer. > > Well, I wouldn't object to reverting it in Linus'

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Fri, Dec 22, 2017 at 09:37:48AM -0800, Brian Norris wrote: > > included in 4.14-rc1, so something needs to be done in Linus's tree to > > resolve this issue, otherwise people will hit this as a regression when > > moving to 4.14 or newer. > > Well, I wouldn't object to reverting it in Linus'

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 01:39:41PM -0800, Guenter Roeck wrote: > On Thu, Dec 21, 2017 at 09:50:57PM +0100, gre...@linuxfoundation.org wrote: > > On Thu, Dec 21, 2017 at 09:46:18PM +0100, gre...@linuxfoundation.org wrote: > > > On Thu, Dec 21, 2017 at 12:04:57PM -0800, G

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 01:39:41PM -0800, Guenter Roeck wrote: > On Thu, Dec 21, 2017 at 09:50:57PM +0100, gre...@linuxfoundation.org wrote: > > On Thu, Dec 21, 2017 at 09:46:18PM +0100, gre...@linuxfoundation.org wrote: > > > On Thu, Dec 21, 2017 at 12:04:57PM -0800, G

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 09:46:18PM +0100, gre...@linuxfoundation.org wrote: > On Thu, Dec 21, 2017 at 12:04:57PM -0800, Guenter Roeck wrote: > > On Thu, Dec 21, 2017 at 11:10:58AM -0800, Brian Norris wrote: > > > On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 09:46:18PM +0100, gre...@linuxfoundation.org wrote: > On Thu, Dec 21, 2017 at 12:04:57PM -0800, Guenter Roeck wrote: > > On Thu, Dec 21, 2017 at 11:10:58AM -0800, Brian Norris wrote: > > > On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 12:04:57PM -0800, Guenter Roeck wrote: > On Thu, Dec 21, 2017 at 11:10:58AM -0800, Brian Norris wrote: > > On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote: > > > >>On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > > > >> Bug: platform can't

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 12:04:57PM -0800, Guenter Roeck wrote: > On Thu, Dec 21, 2017 at 11:10:58AM -0800, Brian Norris wrote: > > On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote: > > > >>On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > > > >> Bug: platform can't

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Wed, Dec 20, 2017 at 11:51:15AM -0800, Brian Norris wrote: > Hi Greg, > > On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > I'm sorry, but I already objected to this one during the discussion

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Wed, Dec 20, 2017 at 11:51:15AM -0800, Brian Norris wrote: > Hi Greg, > > On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > I'm sorry, but I already objected to this one during the discussion

Re: [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

On Wed, Dec 20, 2017 at 09:37:39PM -0500, Martin K. Petersen wrote: > > >> For future patch series submissions, please include a cover letter > >> that explains the purpose of the patch series and please also > >> document the changes between the different versions of the patch > >> series in the

Re: [PATCH 1/2 v3] scsi: ufs: introduce static sysfs entries

On Wed, Dec 20, 2017 at 09:37:39PM -0500, Martin K. Petersen wrote: > > >> For future patch series submissions, please include a cover letter > >> that explains the purpose of the patch series and please also > >> document the changes between the different versions of the patch > >> series in the

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

life time used >04h: 30% ~ 40% device life time used >05h: 40% ~ 50% device life time used >06h: 50% ~ 60% device life time used >07h: 60% ~ 70% device life time used >08h: 70% ~ 80% device life time used >09h: 80% ~ 90% device life time used >0Ah: 90%

Re: [PATCH 2/2 v2] scsi: ufs: use sysfs entry for health info

On Tue, Dec 19, 2017 at 02:46:44PM -0800, Jaegeuk Kim wrote: > >From 3368207da5988b8fed4e41e6c0f49a60ac014222 Mon Sep 17 00:00:00 2001 > From: Jaegeuk Kim > Date: Tue, 26 Sep 2017 20:53:48 -0700 > Subject: [PATCH 2/2] scsi: ufs: introduce sysfs entries exposing UFS health > info > > This patch

Re: [PATCH V1] PM: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 12:07:14PM +, Vikas Bansal wrote: > Description: Why is this here? > > If there is a driver in system which starts creating async schedules > just after resume (Same as our case, in which we faced issue). > Then async_synchronize_full API in PM cores starts waiting

Re: [PATCH V1] PM: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 12:07:14PM +, Vikas Bansal wrote: > Description: Why is this here? > > If there is a driver in system which starts creating async schedules > just after resume (Same as our case, in which we faced issue). > Then async_synchronize_full API in PM cores starts waiting

Re: [PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

On Mon, Dec 04, 2017 at 12:44:32PM +0200, Andrii Vladyka wrote: > Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by > sparse > > Signed-off-by: Andrii Vladyka > Signed-off-by: Andreas Dilger > --- > > diff --git

Re: [PATCH] staging: lustre: Fix sparse, using plain integer as NULL pointer in lov_object_fiemap()

On Mon, Dec 04, 2017 at 12:44:32PM +0200, Andrii Vladyka wrote: > Change 0 to NULL in lov_object_fiemap() in order to fix warning produced by > sparse > > Signed-off-by: Andrii Vladyka > Signed-off-by: Andreas Dilger > --- > > diff --git a/drivers/staging/lustre/lustre/lov/lov_object.c >

Re: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 05:38:31AM +, Vikas Bansal wrote: > If there is a driver in system which starts creating async schedules just > after resume (Same as our case, in which we faced issue). Then > async_synchronize_full API in PM cores starts waiting for completion of async > schedules

Re: In kernel power management domain_pm created for async schedules

On Wed, Dec 06, 2017 at 05:38:31AM +, Vikas Bansal wrote: > If there is a driver in system which starts creating async schedules just > after resume (Same as our case, in which we faced issue). Then > async_synchronize_full API in PM cores starts waiting for completion of async > schedules

Re: UFS utilities

On Tue, Dec 05, 2017 at 03:44:19PM +, Bean Huo (beanhuo) wrote: > Hi, greg k-h > > > > >So what UFS commands are you missing that you need to see implemented? > > > >And again, have you checked the different forks of the driver? > > > > Seems there is something misunderstood, I want to use

Re: UFS utilities

On Tue, Dec 05, 2017 at 03:44:19PM +, Bean Huo (beanhuo) wrote: > Hi, greg k-h > > > > >So what UFS commands are you missing that you need to see implemented? > > > >And again, have you checked the different forks of the driver? > > > > Seems there is something misunderstood, I want to use

Re: [EXT] Re: UFS utilities

On Mon, Dec 04, 2017 at 03:20:34PM +, Bean Huo (beanhuo) wrote: > Hi, Bart > Sorry for later! > > > >Hello Bean, > > > >Please be more specific. What is inconvenient about sg3_utils on embedded > >ARM systems? > > > Exactly, I don't know how to compile sg3_utils with static library, instead >

Re: [EXT] Re: UFS utilities

On Mon, Dec 04, 2017 at 03:20:34PM +, Bean Huo (beanhuo) wrote: > Hi, Bart > Sorry for later! > > > >Hello Bean, > > > >Please be more specific. What is inconvenient about sg3_utils on embedded > >ARM systems? > > > Exactly, I don't know how to compile sg3_utils with static library, instead >

Re: 答复: [PATCH v7,1/2] misc: rtsx: Move Realtek Card Reader Driver to misc

] is here: > > https://patchwork.kernel.org/patch/10076009/ > > Because after the drivers moved from misc to mfd, the [PATCH 2/2] is only > > related to misc, so I send it without cc you. > > If needed, I will cc you in next version. > > Please resubmit the patch-set wi

Re: 答复: [PATCH v7,1/2] misc: rtsx: Move Realtek Card Reader Driver to misc

On Tue, Nov 28, 2017 at 09:33:23AM +, Lee Jones wrote: > On Tue, 28 Nov 2017, 冯锐 wrote: > > > > On Tue, 28 Nov 2017, Lee Jones wrote: > > > > > > > On Tue, 28 Nov 2017, perry.y...@dell.com wrote: > > > > > Hi Greg. > > > > > The Patches have been tested basing on V4.15-rc1 successfully. > >

Re: [PATCH v3] staging: fsl-mc: use 32bits to support 64K size mc-portals

On Wed, Nov 22, 2017 at 10:49:50AM +, Laurentiu Tudor wrote: > > > On 11/22/2017 09:48 AM, Bharat Bhushan wrote: > > As per APIs each mc-portal is of 64K size while currently > > 16bits (type u16) is used to store size of mc-portal. > > In these cases upper bit of portal size gets truncated.

Re: [PATCH v3] staging: fsl-mc: use 32bits to support 64K size mc-portals

On Wed, Nov 22, 2017 at 10:49:50AM +, Laurentiu Tudor wrote: > > > On 11/22/2017 09:48 AM, Bharat Bhushan wrote: > > As per APIs each mc-portal is of 64K size while currently > > 16bits (type u16) is used to store size of mc-portal. > > In these cases upper bit of portal size gets truncated.

Re: [v11,1/4] drivers: jtag: Add JTAG core driver

On Tue, Nov 14, 2017 at 11:19:16AM +, Russell King - ARM Linux wrote: > On Tue, Nov 14, 2017 at 12:10:46PM +0100, gre...@linuxfoundation.org wrote: > > On Tue, Nov 14, 2017 at 10:34:49AM +, Oleksandr Shamray wrote: > > > Greg, what you can suggest about it. May be b

Re: [v11,1/4] drivers: jtag: Add JTAG core driver

On Tue, Nov 14, 2017 at 11:19:16AM +, Russell King - ARM Linux wrote: > On Tue, Nov 14, 2017 at 12:10:46PM +0100, gre...@linuxfoundation.org wrote: > > On Tue, Nov 14, 2017 at 10:34:49AM +, Oleksandr Shamray wrote: > > > Greg, what you can suggest about it. May be b

Re: [v11,1/4] drivers: jtag: Add JTAG core driver

On Tue, Nov 14, 2017 at 10:34:49AM +, Oleksandr Shamray wrote: > > -Original Message- > > From: Chip Bilbrey [mailto:c...@bilbrey.org] > > Sent: Monday, November 6, 2017 12:33 AM > > To: Oleksandr Shamray <oleksan...@mellanox.com> > > Cc: gre..

Re: [v11,1/4] drivers: jtag: Add JTAG core driver

On Tue, Nov 14, 2017 at 10:34:49AM +, Oleksandr Shamray wrote: > > -Original Message- > > From: Chip Bilbrey [mailto:c...@bilbrey.org] > > Sent: Monday, November 6, 2017 12:33 AM > > To: Oleksandr Shamray > > Cc: gre...@linuxfoundation.org;

Re: 答复: [PATCH v2,1/2] misc: rtsx: Move Realtek Card Reader Driver to misc

On Mon, Oct 30, 2017 at 07:50:09AM +, 冯锐 wrote: > Hi Greg > > I'm sorry to bother you, but can you help to review this patch and the patch > below if you have time? > https://patchwork.kernel.org/patch/10026543/ Hm, I don't use patchwork, so I don't know what to say about that. But in

Re: 答复: [PATCH v2,1/2] misc: rtsx: Move Realtek Card Reader Driver to misc

On Mon, Oct 30, 2017 at 07:50:09AM +, 冯锐 wrote: > Hi Greg > > I'm sorry to bother you, but can you help to review this patch and the patch > below if you have time? > https://patchwork.kernel.org/patch/10026543/ Hm, I don't use patchwork, so I don't know what to say about that. But in

Re: 答复: [PATCH] tty: fix flush_to_ldisc() oops before tty_open is done

On Fri, Nov 03, 2017 at 10:48:04AM +, taoyuhong wrote: > Hi Alan > > Serial tty oops on real arm computer. > > That is Hikey960 board, with 8 cortex-a57 cpus and pl011 serial hardware. > Debian8 is pre-installed, and I replaced the kernel with linux-stable 4.13.10. > > It is very easy to

Re: 答复: [PATCH] tty: fix flush_to_ldisc() oops before tty_open is done

On Fri, Nov 03, 2017 at 10:48:04AM +, taoyuhong wrote: > Hi Alan > > Serial tty oops on real arm computer. > > That is Hikey960 board, with 8 cortex-a57 cpus and pl011 serial hardware. > Debian8 is pre-installed, and I replaced the kernel with linux-stable 4.13.10. > > It is very easy to

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 07:57:00AM -0700, Stephen Hemminger wrote: > On Fri, 6 Oct 2017 13:50:44 + > "Stahl, Manuel" wrote: > > > MSI(X) interrupts are not shared between devices. So when available > > those should be preferred over legacy interrupts. >

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 07:57:00AM -0700, Stephen Hemminger wrote: > On Fri, 6 Oct 2017 13:50:44 + > "Stahl, Manuel" wrote: > > > MSI(X) interrupts are not shared between devices. So when available > > those should be preferred over legacy interrupts. > > > > Signed-off-by: Manuel Stahl >

Re: [GIT PULL for-3.18 00/13] Commits for v3.18 LTS

On Wed, Oct 11, 2017 at 12:45:52AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v3.18 LTS. All now pulled in for 3.18, thanks. greg k-h

Re: [GIT PULL for-3.18 00/13] Commits for v3.18 LTS

On Wed, Oct 11, 2017 at 12:45:52AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v3.18 LTS. All now pulled in for 3.18, thanks. greg k-h

Re: [GIT PULL for-4.4 00/25] Commits for v4.4 LTS

On Wed, Oct 11, 2017 at 12:45:38AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v4.4 LTS. All now pulled in, thanks. greg k-h

Re: [GIT PULL for-4.4 00/25] Commits for v4.4 LTS

On Wed, Oct 11, 2017 at 12:45:38AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v4.4 LTS. All now pulled in, thanks. greg k-h

Re: [GIT PULL for-4.9 00/48] Commits for v4.9 LTS

On Wed, Oct 11, 2017 at 12:45:18AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v4.9 LTS. All now pulled in for 4.9-stable, thanks. greg k-h

Re: [GIT PULL for-4.9 00/48] Commits for v4.9 LTS

On Wed, Oct 11, 2017 at 12:45:18AM +, Levin, Alexander (Sasha Levin) wrote: > Hi Greg, > > The following commits were sent for review 7+ days ago, and comments were > addressed. > > Please pull for v4.9 LTS. All now pulled in for 4.9-stable, thanks. greg k-h

Re: Documentation: add Kernel Driver Statement to the kernel

On Sat, Oct 14, 2017 at 08:09:59PM +0200, Wolfram Sang wrote: > > > Not that sphinx doesn't have it's own issues, but you have to admit it > > is much better now than it used to be, right? > > That goes without saying, but we still added plain textfiles to > Documentation/ since 2008, so I was

Re: Documentation: add Kernel Driver Statement to the kernel

On Sat, Oct 14, 2017 at 08:09:59PM +0200, Wolfram Sang wrote: > > > Not that sphinx doesn't have it's own issues, but you have to admit it > > is much better now than it used to be, right? > > That goes without saying, but we still added plain textfiles to > Documentation/ since 2008, so I was

Re: Documentation: add Kernel Driver Statement to the kernel

On Sat, Oct 14, 2017 at 06:14:13PM +0200, Wolfram Sang wrote: > On Fri, Oct 06, 2017 at 11:10:38AM +0200, gre...@linuxfoundation.org wrote: > > Way back in 2008 we didn't have "robust" in-kernel documentation system, > > so the idea of putting something like th

Re: Documentation: add Kernel Driver Statement to the kernel

On Sat, Oct 14, 2017 at 06:14:13PM +0200, Wolfram Sang wrote: > On Fri, Oct 06, 2017 at 11:10:38AM +0200, gre...@linuxfoundation.org wrote: > > Way back in 2008 we didn't have "robust" in-kernel documentation system, > > so the idea of putting something like th

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 01:33:32PM +, Stahl, Manuel wrote: > > Signed-off-by: Manuel Stahl > --- >  drivers/uio/uio_pci_dmem_genirq.c | 27 --- >  drivers/uio/uio_pci_generic.c | 24 ++-- >  2 files changed, 38

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 01:33:32PM +, Stahl, Manuel wrote: > > Signed-off-by: Manuel Stahl > --- >  drivers/uio/uio_pci_dmem_genirq.c | 27 --- >  drivers/uio/uio_pci_generic.c | 24 ++-- >  2 files changed, 38 insertions(+), 13 deletions(-) I

Re: [PATCH] staging: fsl-mc/dpio: Fix incorrect comparison

On Thu, Sep 28, 2017 at 01:07:48PM +, Ruxandra Ioana Radulescu wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Thursday, September 28, 2017 3:49 PM > > To: Ruxandra Ioana Radulescu <ruxandra.rad

Re: [PATCH] staging: fsl-mc/dpio: Fix incorrect comparison

On Thu, Sep 28, 2017 at 01:07:48PM +, Ruxandra Ioana Radulescu wrote: > > -Original Message- > > From: Dan Carpenter [mailto:dan.carpen...@oracle.com] > > Sent: Thursday, September 28, 2017 3:49 PM > > To: Ruxandra Ioana Radulescu > > Cc:

Re: uio_dmem_genirq.c and DMA mapping to user space ?

On Tue, Sep 12, 2017 at 12:18:27PM +, Joakim Tjernlund wrote: > Hi > > I am trying to use the uio_dmem_genirq.c driver for allocating DMA memory to > a PCI device > using the uio_pci_generic.c driver. > > I got as far as defining an UIO dev containing only Dynamic DMA memory and > now I am

Re: uio_dmem_genirq.c and DMA mapping to user space ?

On Tue, Sep 12, 2017 at 12:18:27PM +, Joakim Tjernlund wrote: > Hi > > I am trying to use the uio_dmem_genirq.c driver for allocating DMA memory to > a PCI device > using the uio_pci_generic.c driver. > > I got as far as defining an UIO dev containing only Dynamic DMA memory and > now I am

Re: [alsa-devel] [PATCH] ALSA: msnd: Optimize / harden DSP and MIDI loops

On Tue, Sep 12, 2017 at 09:17:38AM +0200, Takashi Iwai wrote: > On Fri, 08 Sep 2017 19:47:32 +0200, > Grygorii Tertychnyi (gtertych) wrote: > > > > > > >> Hi Greg, > > >> > > >> Could you please apply it for 4.4-stable. > > >> This fixes https://nvd.nist.gov/vuln/detail/CVE-2017-9985 > > > > > >

Re: [alsa-devel] [PATCH] ALSA: msnd: Optimize / harden DSP and MIDI loops

On Tue, Sep 12, 2017 at 09:17:38AM +0200, Takashi Iwai wrote: > On Fri, 08 Sep 2017 19:47:32 +0200, > Grygorii Tertychnyi (gtertych) wrote: > > > > > > >> Hi Greg, > > >> > > >> Could you please apply it for 4.4-stable. > > >> This fixes https://nvd.nist.gov/vuln/detail/CVE-2017-9985 > > > > > >

Re: [PATCH 1/3] thunderbolt: Remove superfluous check

On Wed, Aug 30, 2017 at 02:00:53PM +, Bernat, Yehezkel wrote: > On Mon, 2017-08-28 at 16:20 +0200, Greg Kroah-Hartman wrote: > > On Sun, Aug 27, 2017 at 04:31:27PM +0300, Mika Westerberg wrote: > > > > > > On Tue, Aug 15, 2017 at 10:02:28AM +0300, Mika Westerberg wrote: > > > > > > > > On

Re: [PATCH 1/3] thunderbolt: Remove superfluous check

On Wed, Aug 30, 2017 at 02:00:53PM +, Bernat, Yehezkel wrote: > On Mon, 2017-08-28 at 16:20 +0200, Greg Kroah-Hartman wrote: > > On Sun, Aug 27, 2017 at 04:31:27PM +0300, Mika Westerberg wrote: > > > > > > On Tue, Aug 15, 2017 at 10:02:28AM +0300, Mika Westerberg wrote: > > > > > > > > On

Re: [PATCH 1/1] scsi: ufs: changing maintainer

On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote: > As per internal decision, Joao Pinto will be maintainer for DWC UFS driver. That's "odd", does Joao want this? Do you want this? thanks, greg k-h

Re: [PATCH 1/1] scsi: ufs: changing maintainer

On Tue, Jul 18, 2017 at 09:15:58AM +, Prabu Thangamuthu wrote: > As per internal decision, Joao Pinto will be maintainer for DWC UFS driver. That's "odd", does Joao want this? Do you want this? thanks, greg k-h

Re: [PATCH v3] drivers/char: kmem: disable on arm64

On Tue, Jun 20, 2017 at 01:20:49PM +0200, Ard Biesheuvel wrote: > On 20 June 2017 at 08:59, Ard Biesheuvel wrote: > > As it turns out, arm64 deviates from other architectures in the way it > > maps the VMALLOC region: on most (all?) other architectures, it resides > >

Re: [PATCH v3] drivers/char: kmem: disable on arm64

On Tue, Jun 20, 2017 at 01:20:49PM +0200, Ard Biesheuvel wrote: > On 20 June 2017 at 08:59, Ard Biesheuvel wrote: > > As it turns out, arm64 deviates from other architectures in the way it > > maps the VMALLOC region: on most (all?) other architectures, it resides > > strictly above the kernel's

Re: [PATCH 14/15] kernel: convert futex_pi_state.refcount from atomic_t to refcount_t

On Fri, Jul 07, 2017 at 12:35:16PM +0200, Ingo Molnar wrote: > > * Reshetova, Elena wrote: > > > > On Fri, 7 Jul 2017, Peter Zijlstra wrote: > > > > > > > On Fri, Jul 07, 2017 at 12:04:28PM +0300, Elena Reshetova wrote: > > > > > refcount_t type and corresponding API

Re: [PATCH 14/15] kernel: convert futex_pi_state.refcount from atomic_t to refcount_t

On Fri, Jul 07, 2017 at 12:35:16PM +0200, Ingo Molnar wrote: > > * Reshetova, Elena wrote: > > > > On Fri, 7 Jul 2017, Peter Zijlstra wrote: > > > > > > > On Fri, Jul 07, 2017 at 12:04:28PM +0300, Elena Reshetova wrote: > > > > > refcount_t type and corresponding API should be > > > > > used

Re: [PATCH 3.18 14/36] NFSv4: fix a reference leak caused WARNING messages

On Mon, Jul 03, 2017 at 02:33:29PM +, Trond Myklebust wrote: > Hi Greg, > > On Mon, 2017-07-03 at 15:34 +0200, Greg Kroah-Hartman wrote: > > 3.18-stable review patch.  If anyone has any objections, please let > > me know. > > I cannot find commit a974deee477af89411e0f80456bfb344ac433c98 in >

Re: [PATCH 3.18 14/36] NFSv4: fix a reference leak caused WARNING messages

On Mon, Jul 03, 2017 at 02:33:29PM +, Trond Myklebust wrote: > Hi Greg, > > On Mon, 2017-07-03 at 15:34 +0200, Greg Kroah-Hartman wrote: > > 3.18-stable review patch.  If anyone has any objections, please let > > me know. > > I cannot find commit a974deee477af89411e0f80456bfb344ac433c98 in >

Re: Consult on the Multifunction Composite Gadget problem

On Sat, Jul 01, 2017 at 08:41:20AM +, Lipengcheng wrote: > Hi, > > Now I am prepared based on 3.18 linux kernel development Multifunction > Composite Gadget, which RNDIS + CDC Serial + USB Webcam Gadget, the kernel > community has this development plan, or what needs attention. I have no

Re: Consult on the Multifunction Composite Gadget problem

On Sat, Jul 01, 2017 at 08:41:20AM +, Lipengcheng wrote: > Hi, > > Now I am prepared based on 3.18 linux kernel development Multifunction > Composite Gadget, which RNDIS + CDC Serial + USB Webcam Gadget, the kernel > community has this development plan, or what needs attention. I have no

Re: Stable/distro kernel testing in Plumbers 2017

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > We were hoping to discuss the state of -stable/distro kernel testing > in the Testing & Fuzzing MC in Plumbers 2017. > > Mainly we want to understand what sort of testing is being done, how > bug

Re: Stable/distro kernel testing in Plumbers 2017

On Fri, Jun 23, 2017 at 03:37:28AM +, Levin, Alexander (Sasha Levin) wrote: > Hi all, > > We were hoping to discuss the state of -stable/distro kernel testing > in the Testing & Fuzzing MC in Plumbers 2017. > > Mainly we want to understand what sort of testing is being done, how > bug

Re: tty: possible deadlock in tty_buffer_flush

On Wed, Jun 07, 2017 at 12:42:12AM +, Bart Van Assche wrote: > On Mon, 2017-05-29 at 17:19 +0200, Andrey Konovalov wrote: > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3). > > > >

Re: tty: possible deadlock in tty_buffer_flush

On Wed, Jun 07, 2017 at 12:42:12AM +, Bart Van Assche wrote: > On Mon, 2017-05-29 at 17:19 +0200, Andrey Konovalov wrote: > > I've got the following error report while fuzzing the kernel with syzkaller. > > > > On commit 5ed02dbb497422bf225783f46e6eadd237d23d6b (4.12-rc3). > > > >

Re: [PATCH] staging: sm750fb: Combine set GPIO 30 & 31 into one statement

On Tue, Apr 25, 2017 at 03:53:02PM +, Lynn Lei wrote: > Combine two separate set GPIO(30 & 31) operations into one statement. Why? > > Signed-off-by: Lynn Lei > --- > drivers/staging/sm750fb/ddk750_hwi2c.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) >

Re: [PATCH] staging: sm750fb: Combine set GPIO 30 & 31 into one statement

On Tue, Apr 25, 2017 at 03:53:02PM +, Lynn Lei wrote: > Combine two separate set GPIO(30 & 31) operations into one statement. Why? > > Signed-off-by: Lynn Lei > --- > drivers/staging/sm750fb/ddk750_hwi2c.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git

Re: [PATCH v4] USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Fri, Mar 17, 2017 at 10:56:37AM +, Ajay Kaher wrote: > There is race condition when two USB class drivers try to call > init_usb_class at the same time and leads to crash. > code path: probe->usb_register_dev->init_usb_class > > To solve this, mutex locking has been added in

Re: [PATCH v4] USB: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Fri, Mar 17, 2017 at 10:56:37AM +, Ajay Kaher wrote: > There is race condition when two USB class drivers try to call > init_usb_class at the same time and leads to crash. > code path: probe->usb_register_dev->init_usb_class > > To solve this, mutex locking has been added in

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote: > From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 > From: Ajay Kaher > Date: Thu, 9 Mar 2017 16:07:54 +0530 > Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when >

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Thu, Mar 09, 2017 at 11:34:25AM +, Ajay Kaher wrote: > From febeb10887d5026a489658fd9e911656e76038ac Mon Sep 17 00:00:00 2001 > From: Ajay Kaher > Date: Thu, 9 Mar 2017 16:07:54 +0530 > Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when > two > USB class drivers

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote: >   >   >   > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > >

Re: Subject: [PATCH v4] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Tue, Mar 07, 2017 at 04:35:37AM +, Ajay Kaher wrote: >   >   >   > > On Fri, 3 Mar 2017, Ajay Kaher wrote: > >  > > > > usb_class->kref is not accessible outside the file.c > > > > as usb_class is _static_ inside the file.c and > > > > pointer of usb_class->kref is not passed anywhere. > >

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

On Wed, Mar 08, 2017 at 09:42:09AM +, Reshetova, Elena wrote: > > On Mon, Mar 06, 2017 at 04:20:55PM +0200, Elena Reshetova wrote: > > > refcount_t type and corresponding API should be > > > used instead of atomic_t when the variable is used as > > > a reference counter. This allows to avoid

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, Mar 07, 2017 at 04:54:58PM +, Bart Van Assche wrote: > On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote: > > Somehow all other subsystems work just fine, don't instantly think that > > the driver core needs to bend to the will of the IB code, because you > > are somehow

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, Mar 07, 2017 at 04:54:58PM +, Bart Van Assche wrote: > On Tue, 2017-03-07 at 05:52 +0100, Greg Kroah-Hartman wrote: > > Somehow all other subsystems work just fine, don't instantly think that > > the driver core needs to bend to the will of the IB code, because you > > are somehow

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, Mar 07, 2017 at 02:44:28AM +, Bart Van Assche wrote: > On Tue, 2017-03-07 at 02:41 +, Parav Pandit wrote: > > Compilation would break when CONFIG_PCI is not defined for some embedded > > platforms. > > More than that, including specific pci_dev structure pointer in generic > >

Re: [PATCH 1/2] device: Stop requiring that struct device is embedded in struct pci_dev

On Tue, Mar 07, 2017 at 02:44:28AM +, Bart Van Assche wrote: > On Tue, 2017-03-07 at 02:41 +, Parav Pandit wrote: > > Compilation would break when CONFIG_PCI is not defined for some embedded > > platforms. > > More than that, including specific pci_dev structure pointer in generic > >

Re: [4.11.0-rc1] kernel warning due to commit 3bb434cd, "vmw_vmci: switch to pci_irq_alloc_vectors"

On Mon, Mar 06, 2017 at 07:02:16AM +, 허종만 wrote: >   > > Hi, > > I'm running kernel 4.11-rc1 on VMWare Workstation 12 Pro (Host : windows 10, > Guest : Fedora 25). > > > I got kernel warning with latest kernel. > > According to git bisect, first bad commit is >

Re: [4.11.0-rc1] kernel warning due to commit 3bb434cd, "vmw_vmci: switch to pci_irq_alloc_vectors"

On Mon, Mar 06, 2017 at 07:02:16AM +, 허종만 wrote: >   > > Hi, > > I'm running kernel 4.11-rc1 on VMWare Workstation 12 Pro (Host : windows 10, > Guest : Fedora 25). > > > I got kernel warning with latest kernel. > > According to git bisect, first bad commit is >

Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote: >   > >> At boot time, probe function of multiple connected devices > >> (proprietary devices) execute simultaneously. > > > >What exactly do you mean here? How can probe happen "simultaneously"? > >The USB core prevents this, right? >

Re: Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Wed, Feb 01, 2017 at 07:24:44AM +, Ajay Kaher wrote: >   > >> At boot time, probe function of multiple connected devices > >> (proprietary devices) execute simultaneously. > > > >What exactly do you mean here? How can probe happen "simultaneously"? > >The USB core prevents this, right? >

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I

Re: Subject: [PATCH v1] USB:Core: BugFix: Proper handling of Race Condition when two USB class drivers try to call init_usb_class simultaneously

On Mon, Jan 30, 2017 at 08:25:25AM +, Ajay Kaher wrote: > First off, you are sending html email, which the mailing list keeps rejecting, why are you ignoring that? > > There is race condition when two USB class drivers try to call > > init_usb_class at the same time and leads to crash.

<    1   2   3   4   5   6   7   8   >