看热门大片不花钱

爱奇艺vip分享QQ群：5650047每天分享一大波爱奇艺会员帐号，看热门大片不花钱！ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] realtek: rtlwifi: rtl8821ae: Fix lockups on boot

On 11/12/2015 01:54 PM, Kalle Valo wrote: Larry Finger writes: In commit 54328e64047a5 ("rtlwifi: rtl8821ae: Fix system lockups on boot"), an attempt was made to fix a regression introduced in commit 1277fa2ab2f9 ("rtlwifi: Remove the clear interrupt routine from

RE: [PATCH 3/9] staging: unisys: visorinput: use kref ref-counting for device data struct

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 12, 2015 4:28 PM > To: Sell, Timothy C > Cc: Romer, Benjamin M; driverdev-devel@linuxdriverproject.org; *S-Par- > Maintainer > Subject: Re: [PATCH 3/9] staging: unisys: visorinput: use kref

Re: [PATCH 3/9] staging: unisys: visorinput: use kref ref-counting for device data struct

On Thu, Nov 12, 2015 at 09:07:24PM +, Sell, Timothy C wrote: > What should I do with this patchset? What patchset? > Some history: it was fixing this one little line in > drivers/staging/unisys/visorinput/Kconfig that triggered this patchset: > > depends on UNISYSSPAR &&

RE: [PATCH 3/9] staging: unisys: visorinput: use kref ref-counting for device data struct

> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, November 12, 2015 4:12 PM > To: Sell, Timothy C > Cc: Romer, Benjamin M; driverdev-devel@linuxdriverproject.org; *S-Par- > Maintainer > Subject: Re: [PATCH 3/9] staging: unisys: visorinput: use kref

Re: [PATCH] realtek: rtlwifi: rtl8821ae: Fix lockups on boot

Larry Finger writes: > In commit 54328e64047a5 ("rtlwifi: rtl8821ae: Fix system lockups on boot"), > an attempt was made to fix a regression introduced in commit 1277fa2ab2f9 > ("rtlwifi: Remove the clear interrupt routine from all drivers"). > Unfortunately, there

HFI1 code duplication todo

The major todo for the hfi1 driver in staging is getting rid of the verbs code duplication between ipath, qib, and now hfi1. The ipath driver has been deprecated and is going to be deleted soon. So that leaves qib and hfi. To address this we have proposed rdmavt which will be a common kmod that

RE: [PATCH 3/9] staging: unisys: visorinput: use kref ref-counting for device data struct

What should I do with this patchset? Some history: it was fixing this one little line in drivers/staging/unisys/visorinput/Kconfig that triggered this patchset: depends on UNISYSSPAR && UNISYS_VISORBUS && FB Adding "INPUT" was easy, but it turned out that removing "FB" was hard. ;-(

Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization

Hi arnd, I appreciate the patches. I did test this patch series on h/w which is arm based MCU. From this patch wilc is not working properly. After downloading firmware, the firmware cannot start and it fails. I double check this patch and the previous one(14/20) which works fine. I cannot find

Re: [lustre-devel] [PATCH] staging: lustre: cl_lock: Remove cl_lock_lockdep_init wrapper

On 2015/11/11, 10:21, "lustre-devel on behalf of Shivani Bhardwaj" wrote: >On Wed, Nov 11, 2015 at 4:24 PM, kbuild test robot wrote: >> Hi Shivani, >> >> [auto build test ERROR on staging/staging-testing]

Re: [PATCH 3/9] staging: unisys: visorinput: use kref ref-counting for device data struct

On Thu, Nov 12, 2015 at 09:21:14PM +, Sell, Timothy C wrote: > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Thursday, November 12, 2015 4:12 PM > > To: Sell, Timothy C > > Cc: Romer, Benjamin M; driverdev-devel@linuxdriverproject.org; *S-Par- > >

[PATCH] staging: comedi: adv_pci_dio: separate out PCI-1760 support

The PCI-1760 board unique. It uses a outgoing/incoming mailbox programming sequence to access the hardware. The other boards supported by this driver use simple register mapping. Including support for the PCI-1760 in this driver just makes it harder to understand. Separate out the PCI-1760

[PATCH 0/4] Drivers: hv: utils: prevent crash when a utility driver is disabled host side

I'm observing a crash when a utility driver is disabled host side (e.g. 'Guest services' is disabled live) when we have userspace daemon connected: [ 90.244859] general protection fault: [#1] SMP ... [ 90.800082] CPU: 3 PID: 473 Comm: hypervfcopyd Not tainted 4.3.0-rc7_netvsc_noalloc+

[PATCH 2/4] Drivers: hv: utils: rename outmsg_lock

As a preparation to reusing outmsg_lock to protect test-and-set openrations on 'mode' rename it the more general 'lock'. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_utils_transport.c | 14 +++--- drivers/hv/hv_utils_transport.h | 2 +- 2 files changed, 8

[PATCH 3/4] Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode

When Hyper-V host asks us to remove some util driver by closing the appropriate channel there is no easy way to force the current file descriptor holder to hang up but we can start to respond -EBADF to all operations asking it to exit gracefully. As we're setting hvt->mode from two separate

[PATCH 1/4] Drivers: hv: utils: fix memory leak on on_msg() failure

inmsg should be freed in case of on_msg() failure to avoid memory leak. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_utils_transport.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/hv/hv_utils_transport.c

[PATCH 4/4] Drivers: hv: utils: fix crash when device is removed from host side

The crash is observed when a service is being disabled host side while userspace daemon is connected to the device: [ 90.244859] general protection fault: [#1] SMP ... [ 90.800082] Call Trace: [ 90.800082] [] __fput+0xc8/0x1f0 [ 90.800082] [] fput+0xe/0x10 ... [ 90.800082]

RE: [PATCH 12/13] staging/rdma/hfi1: Read EFI variable for device description

> -Original Message- > From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, November 11, 2015 11:24 AM > > If you move the variables to the top and have the early return as you > > suggest, > then in some CONFIG cases, there will be all those automatic

Re: [PATCH V2 10/12] Drivers: hv: vmbus: channge vmbus_connection.channel_lock to mutex

"K. Y. Srinivasan" writes: > From: Dexuan Cui > > spinlock is unnecessary here. > mutex is enough. Hm, mutex is usually required when we need to sleep and a spinlock is enough otherwise :-) Or are you trying to say we don't need to disable interrupts

Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization

On Thursday 12 November 2015 19:05:41 glen lee wrote: > Hi arnd, > > I appreciate the patches. > I did test this patch series on h/w which is arm based MCU. > From this patch wilc is not working properly. After downloading firmware, > the firmware cannot start and it fails. > I double check

Re: [PATCH 15/20] staging/wilc1000: pass hif operations through initialization

On 2015년 11월 12일 20:39, Arnd Bergmann wrote: On Thursday 12 November 2015 19:05:41 glen lee wrote: Hi arnd, I appreciate the patches. I did test this patch series on h/w which is arm based MCU. From this patch wilc is not working properly. After downloading firmware, the firmware cannot

Re: [PATCH] staging/rdma/hfi1: Reduce number of parameters passed to send handlers

On Thu, Nov 12, 2015 at 08:04:01AM +0200, Or Gerlitz wrote: On Wed, Nov 11, 2015 at 3:39 PM, Dennis Dalessandro wrote: On Wed, Nov 11, 2015 at 08:25:35AM +0200, Leon Romanovsky wrote: On Wed, Nov 11, 2015 at 12:34:37AM -0500, ira.we...@intel.com wrote: From:

RE: [PATCH V2 10/12] Drivers: hv: vmbus: channge vmbus_connection.channel_lock to mutex

> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Thursday, November 12, 2015 18:41 > To: Dexuan Cui > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com; KY

Re: [PATCH] staging/rdma/hfi1: Reduce number of parameters passed to send handlers

On Thu, Nov 12, 2015 at 3:25 PM, Dennis Dalessandro wrote: > On Thu, Nov 12, 2015 at 08:04:01AM +0200, Or Gerlitz wrote: >> Dennis, can we have less camelcase sort of speak in this upstream driver? >> this is linux here not windowZ. > I plan to just remove this

Re: [PATCH] comedi: ni_6527: Fix coding style - use BIT macro

On 11/11/15 16:14, Ranjith Thangavel wrote: BIT macro is used for defining BIT location instead of shifting operator - coding style issue Signed-off-by: Ranjith Thangavel --- drivers/staging/comedi/drivers/ni_6527.c | 24 1 file changed, 12

Re: [PATCH] comedi: cb_pcidda: Fix coding style - use BIT macro

On 11/11/15 16:27, Ranjith Thangavel wrote: BIT macro is used for defining BIT location instead of shifting operator - coding style issue Signed-off-by: Ranjith Thangavel --- drivers/staging/comedi/drivers/cb_pcidda.c |6 +++--- 1 file changed, 3 insertions(+), 3

Re: [PATCH] comedi: comedi_parport: Fix coding style - use BIT macro

On 11/11/15 15:54, Ranjith Thangavel wrote: BIT macro is used for defining BIT location instead of shifting operator - coding style issue Signed-off-by: Ranjith Thangavel --- drivers/staging/comedi/drivers/comedi_parport.c |4 ++-- 1 file changed, 2

Re: [PATCH] comedi: cb_pcidda: Fix coding style - use BIT macro

On Wed, Nov 11, 2015 at 2:27 PM, Ranjith Thangavel wrote: > BIT macro is used for defining BIT location instead of > shifting operator - coding style issue I would not call it a coding style issue. ___ devel mailing list

Re: [PATCH] comedi: pcmmio.c: Fix coding style - use BIT macro

On 11/11/15 15:48, Ranjith Thangavel wrote: BIT macro is used for defining BIT location instead of shifting operator - coding style issue Signed-off-by: Ranjith Thangavel --- drivers/staging/comedi/drivers/pcmmio.c | 44 +++ 1 file

Re: [PATCH] comedi: ni_65xx: Fix coding style - use BIT macro

On 11/11/15 16:22, Ranjith Thangavel wrote: BIT macro is used for defining BIT location instead of shifting operator - coding style issue Signed-off-by: Ranjith Thangavel --- drivers/staging/comedi/drivers/ni_65xx.c | 54 +++--- 1 file

RE: [PATCH 1/1] drivers/hv: correct tsc page sequence invalid value

> -Original Message- > From: Denis V. Lunev [mailto:d...@openvz.org] > Sent: Wednesday, November 11, 2015 11:16 PM > To: KY Srinivasan > Cc: rka...@virtuozzo.com; de...@linuxdriverproject.org; linux- > ker...@vger.kernel.org; Andrey Smetanin

Re: [PATCH 1/1] drivers/hv: correct tsc page sequence invalid value

On 11/12/2015 08:35 PM, KY Srinivasan wrote: -Original Message- From: Denis V. Lunev [mailto:d...@openvz.org] Sent: Wednesday, November 11, 2015 11:16 PM To: KY Srinivasan Cc: rka...@virtuozzo.com; de...@linuxdriverproject.org; linux- ker...@vger.kernel.org; Andrey