看热门大片不花钱

2015-11-12 Thread vip分享群 
爱奇艺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

2015-11-12 Thread Larry Finger 

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 all drivers").
Unfortunately, there were logic errors in that patch that prevented
affected boxes from booting even after that patch was applied.

The actual cause of the original problem is unknown as none of the
developers have systems that are affected.

Signed-off-by: Larry Finger 
Cc: Stable  [V4.1+]


I think the "realtek:" prefix is superfluous, "rtlwifi:" should be
enough. I'll also add a fixes line before I commit this:

Fixes: 54328e64047a ("rtlwifi: rtl8821ae: Fix system lockups on boot")


I'll drop the extra prefix in the future. Your extra line is good.

Larry


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Sell, Timothy C 
> -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 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-
> > > Maintainer
> > > Subject: 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?
> >
> > "[PATCH 0/9] staging: unisys: visorinput fixes and enhancements",
> > submitted by Ben Romer Fri 10/16/2015 @ 10:07 AM.
> 
> I don't see this in my "to-review" queue at all, sorry.  If this was
> some old patchset, you are going to have to resend as my memory is
> totally gone (remember, I get 1000 emails a day, and my to-review mbox
> is right now 1637 emails to process once the merge window opens up...)
> 
> > > > 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.
> > > ;-(
> > > > Removing FB is at the crux of this patchset.
> > > >
> > > > Rarely a week passes where I don't get a complaint from the
> > > > community about the fact that I need to add "INPUT" to that line to fix
> > > > errors when building with randconfig.
> > >
> > > Then submit a patch that fixes that! :)
> >
> > That's what I did, originally.  But you told me I had to get rid of the FB
> > requirement.  So  that's why we submitted
> > "[PATCH 0/9] staging: unisys: visorinput fixes and enhancements", which
> > includes all the stuff we needed to get rid of FB as well as the last
> > patch in the series, which adds INPUT.
> > Ben Romer actually submitted the patchset Fri 10/16/2015 @ 10:07 AM.
> 
> It's not in my queue, so I have no idea what happened to it.  Did I
> apply it?  Reject it?  something else?
> 
> thanks,
> 
> greg k-h

We were bantering back-and-forth about a lock, but the thread stopped
without a conclusion.  You definitely did NOT apply it.

No problem.  We'll just re-submit the set.

Thanks.

Tim Sell
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Greg KH 
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 && UNISYS_VISORBUS && FB
> 
> Adding "INPUT" was easy, but it turned out that removing "FB" was hard.  ;-(
> Removing FB is at the crux of this patchset.
> 
> Rarely a week passes where I don't get a complaint from the
> community about the fact that I need to add "INPUT" to that line to fix
> errors when building with randconfig.

Then submit a patch that fixes that! :)

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Sell, Timothy C 
> -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 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?

"[PATCH 0/9] staging: unisys: visorinput fixes and enhancements", 
submitted by Ben Romer Fri 10/16/2015 @ 10:07 AM.

> > 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.
> ;-(
> > Removing FB is at the crux of this patchset.
> >
> > Rarely a week passes where I don't get a complaint from the
> > community about the fact that I need to add "INPUT" to that line to fix
> > errors when building with randconfig.
> 
> Then submit a patch that fixes that! :)

That's what I did, originally.  But you told me I had to get rid of the FB
requirement.  So  that's why we submitted 
"[PATCH 0/9] staging: unisys: visorinput fixes and enhancements", which
includes all the stuff we needed to get rid of FB as well as the last
patch in the series, which adds INPUT.
Ben Romer actually submitted the patchset Fri 10/16/2015 @ 10:07 AM.

Tim Sell

> 
> thanks,
> 
> greg k-h

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Kalle Valo 
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 were logic errors in that patch that prevented
> affected boxes from booting even after that patch was applied.
>
> The actual cause of the original problem is unknown as none of the
> developers have systems that are affected.
>
> Signed-off-by: Larry Finger 
> Cc: Stable  [V4.1+]

I think the "realtek:" prefix is superfluous, "rtlwifi:" should be
enough. I'll also add a fixes line before I commit this:

Fixes: 54328e64047a ("rtlwifi: rtl8821ae: Fix system lockups on boot")

-- 
Kalle Valo
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

HFI1 code duplication todo

2015-11-12 Thread Dennis Dalessandro 
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 
provides software RDMA verbs support. qib and hfi1 will both use this as 
well as other forthcoming drivers such as soft-roce. See this thread for 
some details: http://www.spinics.net/lists/linux-rdma/msg29922.html.


Since that initial RFC we have been accumulating patches in a GitHub repo 
for an early look at the development. At some point soon we want to actually 
start posting the patches to the mailing list. This is where it gets tricky.  
The code basically not only adds a new driver but it modifies two existing 
ones, heavily. To make it more murky one driver is in staging the other is 
in the usual drivers/infiniband tree.


The question is, how do we go about this logistically due to the 2 drivers 
being in separate sub-trees?


Greg, Doug,
As the maintainers of the two trees involved we'd kind of like to get your 
thoughts on this.


Thanks

-Denny
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Sell, Timothy C 
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.  ;-(
Removing FB is at the crux of this patchset.

Rarely a week passes where I don't get a complaint from the
community about the fact that I need to add "INPUT" to that line to fix
errors when building with randconfig.

Thanks.

Tim Sell

> -Original Message-
> From: Sell, Timothy C
> Sent: Saturday, October 17, 2015 2:10 PM
> To: 'Greg KH'
> Cc: Romer, Benjamin M; driverdev-devel@linuxdriverproject.org; *S-Par-
> Maintainer
> Subject: 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: Saturday, October 17, 2015 1:41 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 ref-counting
> > for device data struct
> >
> > On Sat, Oct 17, 2015 at 05:04:43PM +, Sell, Timothy C wrote:
> > > > -Original Message-
> > > > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > > > Sent: Saturday, October 17, 2015 12:51 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 ref-
> counting
> > > > for device data struct
> > > >
> > > > On Sat, Oct 17, 2015 at 04:34:28PM +, Sell, Timothy C wrote:
> > > > > > How can you guarantee it?  Please document that somehow, I don't
> > see
> > > > it
> > > > > > here in this patch how that can be true, but maybe I'm not looking
> > close
> > > > > > enough...
> > > > >
> > > > > Sure; I'll add some code comments.  Basically they will amount to
> this:
> > > > > * The kref is initialized to 1 in _probe(), and the book-end for that 
> > > > > is
> > > > > the devdata_put() in _remove().
> > > > > * devdata_get() / devdata_put() is called to keep the ref valid during
> > > > > interrupt processing in visorinput_channel_interrupt().  The visorbus
> > > > > model guarantees that at most 1 thread of execution will ever be
> > > > > running this function at a time.
> > > > > * We are guaranteed that the kref will be >= 1 when entering
> > > > > visorinput_channel_interrupt(), and that no other thread of
> execution
> > can
> > > > > do a kref_put() at that point, because the devdata_put()
> > > > > in _remove() is only done AFTER disabling interrupts.  Once
> > > > > interrupts are disabled, NO thread of execution will be running
> > > > > visorinput_channel_interrupt().
> > > >
> > > > So the lifetime of this kref mirrors the lifetime of the struct device?
> > > > Why have a kref at all then?
> > > >
> > > > > * "[PATCH 6/9] staging: unisys: visorinput: respond to resolution
> > changes
> > > > on-the-fly"
> > > > > (a subsequent patch in this series)
> > > > > requires that devdata be accessed from a workqueue, but does the
> > > > > required devdata_get() before queuing the work (which occurs in
> > > > > visorinput_channel_interrupt(), where we know the kref count is
> > actually
> > > > >= 2),
> > > > > and devdata_put() after the work is processed.  Because
> devdata_get()
> > is
> > > > > NEVER done at a time when it is possible that the kref is 0, we do NOT
> > > > > require a lock.
> > > > > * In actuality, there is only 1 scenario when devdata_get()/_put()
> could
> > be
> > > > > running on > 1 thread of execution simultaneously: The
> devdata_put()
> > > > > performed after processing of the workitem can occur
> asynchronously
> > > > with
> > > > > the devdata_put in _remove().  But since those both involve only
> > > > kref_put(),
> > > > > we are safe calling them on multiple threads without a lock, as only
> the
> > > > last
> > > > > one will be calling release(), due to atomic operation in kref_put().
> > > > >
> > > > > I don't see a case for needing a lock, but of course it's entirely
> possible
> > > > > that I've missed something.
> > > > >
> > > > > Honestly, I was a bit surprised to see how FEW usages of
> > > > > kref_put_mutex() and kref_put_spinlock_irqsave() there actually
> were
> > > > > in the kernel.
> > > >
> > > > Well, most of the usages are probably wrong, let's not continue to
> write
> > > > bad code :)
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > >
> > > AGREED!
> > >
> > > Are you also suggesting that I should use one of the kref locking
> > > variants here?   I can do that NO problem, as I'm sure it can't hurt
> > > anything, but as I explained above, I just don't see why I need it.
> > > (I'm NOT above admitting my "why I don't need a lock" logic could be
> > > flawed...)
> >
> > If your reference counting model

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

2015-11-12 Thread glen lee 

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 the problem in this patch at the moment. I will see if I can find 
something,
and I'd appreciate if you would help with it.

regards,
glen lee


On 2015년 11월 11일 08:42, Arnd Bergmann wrote:

The wilc_hif_spi and wilc_hif_sdio structures are part of
the bus specific code, and the generic code should have no knowledge
of their addresses.

This changes the code to reference them only from the bus
specific initialization code, which we can then use to split
up the driver into separate modules.

Signed-off-by: Arnd Bergmann 
---
  drivers/staging/wilc1000/linux_wlan.c |  4 ++-
  drivers/staging/wilc1000/linux_wlan_sdio.c|  3 ++-
  drivers/staging/wilc1000/linux_wlan_spi.c |  2 +-
  drivers/staging/wilc1000/wilc_sdio.c  | 35 +--
  drivers/staging/wilc1000/wilc_spi.c   | 34 +-
  drivers/staging/wilc1000/wilc_wfi_netdevice.h |  4 ++-
  drivers/staging/wilc1000/wilc_wlan.c  | 15 ++--
  drivers/staging/wilc1000/wilc_wlan.h  |  4 +--
  8 files changed, 47 insertions(+), 54 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index e81e90678d0f..2fb1d97bded1 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1408,7 +1408,8 @@ void wilc_netdev_cleanup(struct wilc *wilc)
  #endif
  }
  
-int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type, int gpio)

+int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type,
+int gpio, const struct wilc_hif_func *ops)
  {
int i;
perInterface_wlan_t *nic;
@@ -1423,6 +1424,7 @@ int wilc_netdev_init(struct wilc **wilc, struct device 
*dev, int io_type, int gp
*wilc = wilc_dev;
wilc_dev->io_type = io_type;
wilc_dev->gpio = gpio;
+   wilc_dev->ops = ops;
  
  	register_inetaddr_notifier(_dev_notifier);
  
diff --git a/drivers/staging/wilc1000/linux_wlan_sdio.c b/drivers/staging/wilc1000/linux_wlan_sdio.c

index 732b0d66366b..f4250fda6cf1 100644
--- a/drivers/staging/wilc1000/linux_wlan_sdio.c
+++ b/drivers/staging/wilc1000/linux_wlan_sdio.c
@@ -119,7 +119,8 @@ static int linux_sdio_probe(struct sdio_func *func, const 
struct sdio_device_id
  
  	PRINT_D(INIT_DBG, "Initializing netdev\n");

wilc_sdio_func = func;
-   if (wilc_netdev_init(, >dev, HIF_SDIO, gpio)) {
+   if (wilc_netdev_init(, >dev, HIF_SDIO, gpio,
+_hif_sdio)) {
PRINT_ER("Couldn't initialize netdev\n");
return -1;
}
diff --git a/drivers/staging/wilc1000/linux_wlan_spi.c 
b/drivers/staging/wilc1000/linux_wlan_spi.c
index f4dda4a6fa7b..a7a52593156a 100644
--- a/drivers/staging/wilc1000/linux_wlan_spi.c
+++ b/drivers/staging/wilc1000/linux_wlan_spi.c
@@ -404,7 +404,7 @@ static int __init init_wilc_spi_driver(void)
  
  	wilc_debugfs_init();
  
-	ret = wilc_netdev_init(, NULL, HIF_SPI, GPIO_NUM);

+   ret = wilc_netdev_init(, NULL, HIF_SPI, GPIO_NUM, _hif_spi);
if (ret) {
wilc_debugfs_remove();
return ret;
diff --git a/drivers/staging/wilc1000/wilc_sdio.c 
b/drivers/staging/wilc1000/wilc_sdio.c
index 8441fcc4..0a9b5a71772e 100644
--- a/drivers/staging/wilc1000/wilc_sdio.c
+++ b/drivers/staging/wilc1000/wilc_sdio.c
@@ -912,23 +912,22 @@ static int sdio_sync_ext(int nint /*  how mant interrupts 
to enable. */)
   *
   /
  
-struct wilc_hif_func wilc_hif_sdio = {

-   sdio_init,
-   sdio_deinit,
-   sdio_read_reg,
-   sdio_write_reg,
-   sdio_read,
-   sdio_write,
-   sdio_sync,
-   sdio_clear_int,
-   sdio_read_int,
-   sdio_clear_int_ext,
-   sdio_read_size,
-   sdio_write,
-   sdio_read,
-   sdio_sync_ext,
-
-   sdio_set_max_speed,
-   sdio_set_default_speed,
+const struct wilc_hif_func wilc_hif_sdio = {
+   .hif_init = sdio_init,
+   .hif_deinit = sdio_deinit,
+   .hif_read_reg = sdio_read_reg,
+   .hif_write_reg = sdio_write_reg,
+   .hif_block_rx = sdio_read,
+   .hif_block_tx = sdio_write,
+   .hif_sync = sdio_sync,
+   .hif_clear_int = sdio_clear_int,
+   .hif_read_int = sdio_read_int,
+   .hif_clear_int_ext = sdio_clear_int_ext,
+   .hif_read_size = sdio_read_size,
+   .hif_block_rx_ext = sdio_write,
+   .hif_block_tx_ext = sdio_read,
+   .hif_sync_ext = sdio_sync_ext,
+   .hif_set_max_bus_speed = sdio_set_max_speed,
+   .hif_set_default_bus_speed = sdio_set_default_speed,
  };
  
diff --git

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

2015-11-12 Thread Dilger, Andreas 
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]
>> [also build test ERROR on v4.3 next-2015]
>>
>> url:
>>https://github.com/0day-ci/linux/commits/Shivani-Bhardwaj/staging-lustre-
>>cl_lock-Remove-cl_lock_lockdep_init-wrapper/2015-182452
>> config: m68k-allyesconfig (attached as .config)
>> reproduce:
>> wget 
>>https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin
>>/make.cross -O ~/bin/make.cross
>> chmod +x ~/bin/make.cross
>> # save the attached .config to linux build tree
>> make.cross ARCH=m68k
>>
>> All errors (new ones prefixed by >>):
>>
>>In file included from include/linux/spinlock_types.h:18:0,
>> from include/linux/spinlock.h:81,
>> from include/linux/mmzone.h:7,
>> from include/linux/gfp.h:5,
>> from include/linux/slab.h:14,
>> from
>>drivers/staging/lustre/lustre/obdclass/../include/obd_support.h:40,
>> from
>>drivers/staging/lustre/lustre/obdclass/../include/obd_class.h:39,
>> from
>>drivers/staging/lustre/lustre/obdclass/cl_lock.c:43:
>>drivers/staging/lustre/lustre/obdclass/cl_lock.c: In function
>>'cl_lock_alloc':
 drivers/staging/lustre/lustre/obdclass/cl_lock.c:379:37: error:
'cl_lock_key' undeclared (first use in this function)
>>   lockdep_set_class_and_name(lock, _lock_key, "EXT");
>> ^
>>include/linux/lockdep.h:401:15: note: in definition of macro
>>'lockdep_set_class_and_name'
>>   do { (void)(key); (void)(name); } while (0)
>>   ^
>>drivers/staging/lustre/lustre/obdclass/cl_lock.c:379:37: note: each
>>undeclared identifier is reported only once for each function it appears
>>in
>>   lockdep_set_class_and_name(lock, _lock_key, "EXT");
>> ^
>>include/linux/lockdep.h:401:15: note: in definition of macro
>>'lockdep_set_class_and_name'
>>   do { (void)(key); (void)(name); } while (0)
>>   ^
>>drivers/staging/lustre/lustre/obdclass/cl_lock.c: At top level:
>>drivers/staging/lustre/lustre/obdclass/cl_lock.c:166:13: warning:
>>'cl_lock_lockdep_init' defined but not used [-Wunused-function]
>> static void cl_lock_lockdep_init(struct cl_lock *lock)
>> ^
>>
>> vim +/cl_lock_key +379 drivers/staging/lustre/lustre/obdclass/cl_lock.c
>>
>>373  lockdep_set_class(>cll_guard,
>>_lock_guard_class);
>>374  init_waitqueue_head(>cll_wq);
>>375  head = obj->co_lu.lo_header;
>>376  CS_LOCKSTATE_INC(obj, CLS_NEW);
>>377  CS_LOCK_INC(obj, total);
>>378  CS_LOCK_INC(obj, create);
>>  > 379  lockdep_set_class_and_name(lock, _lock_key,
>>"EXT");
>>380  list_for_each_entry(obj, >loh_layers,
>>381  co_lu.lo_linkage) {
>>382  int err;
>>
>> ---
>> 0-DAY kernel test infrastructureOpen Source Technology
>>Center
>> https://lists.01.org/pipermail/kbuild-all   Intel
>>Corporation
>
>Hi all,
>
>I'm not getting any of these errors at compilation. I've checked
>thrice. Could you please tell what am I doing wrong so that I can
>avoid introducing errors in future patches?

You need to have CONFIG_LOCKDEP_SUPPORT=y in your kernel .config file.

Cheers, Andreas
-- 
Andreas Dilger

Lustre Principal Engineer
Intel High Performance Data Division


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Greg KH 
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-
> > Maintainer
> > Subject: 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?
> 
> "[PATCH 0/9] staging: unisys: visorinput fixes and enhancements", 
> submitted by Ben Romer Fri 10/16/2015 @ 10:07 AM.

I don't see this in my "to-review" queue at all, sorry.  If this was
some old patchset, you are going to have to resend as my memory is
totally gone (remember, I get 1000 emails a day, and my to-review mbox
is right now 1637 emails to process once the merge window opens up...)

> > > 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.
> > ;-(
> > > Removing FB is at the crux of this patchset.
> > >
> > > Rarely a week passes where I don't get a complaint from the
> > > community about the fact that I need to add "INPUT" to that line to fix
> > > errors when building with randconfig.
> > 
> > Then submit a patch that fixes that! :)
> 
> That's what I did, originally.  But you told me I had to get rid of the FB
> requirement.  So  that's why we submitted 
> "[PATCH 0/9] staging: unisys: visorinput fixes and enhancements", which
> includes all the stuff we needed to get rid of FB as well as the last
> patch in the series, which adds INPUT.
> Ben Romer actually submitted the patchset Fri 10/16/2015 @ 10:07 AM.

It's not in my queue, so I have no idea what happened to it.  Did I
apply it?  Reject it?  something else?

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread H Hartley Sweeten 
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 support into a new driver, adv_pci1760.

Clean up the new driver. The original code had a bunch of CamelCase and
other checkpatch.pl issues.

The code used to access the outgoing/incoming mailboxes was also a bit
awkward with the passing of the arrays for the outgoing and incoming
mailbox bytes. Replace them with two new functions that send a command
and return the feedback data from the command based on the programming
flow chart in the datasheet for the PCI-1760.

The new adv_pci1760 driver also fixes the incomplete timer subdevice.
This subdevice is actually the 2 PWM outputs so the subdevice type
has been changed to COMEDI_SUBD_PWM.

The counter subdevice support was not complete in the original code.
For now that subdevice has been disabled (COMEDI_SUBD_UNUSED).

Signed-off-by: H Hartley Sweeten 
Cc: Ian Abbott 
Cc: Greg Kroah-Hartman 
---
 drivers/staging/comedi/Kconfig   |  12 +-
 drivers/staging/comedi/drivers/Makefile  |   1 +
 drivers/staging/comedi/drivers/adv_pci1760.c | 432 +++
 drivers/staging/comedi/drivers/adv_pci_dio.c | 417 +-
 4 files changed, 445 insertions(+), 417 deletions(-)
 create mode 100644 drivers/staging/comedi/drivers/adv_pci1760.c

diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
index 945c85a..e7255f8 100644
--- a/drivers/staging/comedi/Kconfig
+++ b/drivers/staging/comedi/Kconfig
@@ -772,6 +772,14 @@ config COMEDI_ADV_PCI1724
  To compile this driver as a module, choose M here: the module will be
  called adv_pci1724.
 
+config COMEDI_ADV_PCI1760
+   tristate "Advantech PCI-1760 support"
+   ---help---
+ Enable support for Advantech PCI-1760 board.
+
+ To compile this driver as a module, choose M here: the module will be
+ called adv_pci1760.
+
 config COMEDI_ADV_PCI_DIO
tristate "Advantech PCI DIO card support"
select COMEDI_8254
@@ -779,8 +787,8 @@ config COMEDI_ADV_PCI_DIO
---help---
  Enable support for Advantech PCI DIO cards
  PCI-1730, PCI-1733, PCI-1734, PCI-1735U, PCI-1736UP, PCI-1739U,
- PCI-1750, PCI-1751, PCI-1752, PCI-1753/E, PCI-1754, PCI-1756,
- PCI-1760 and PCI-1762
+ PCI-1750, PCI-1751, PCI-1752, PCI-1753/E, PCI-1754, PCI-1756 and
+ PCI-1762
 
  To compile this driver as a module, choose M here: the module will be
  called adv_pci_dio.
diff --git a/drivers/staging/comedi/drivers/Makefile 
b/drivers/staging/comedi/drivers/Makefile
index 94c179b..0c8cfa7 100644
--- a/drivers/staging/comedi/drivers/Makefile
+++ b/drivers/staging/comedi/drivers/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_COMEDI_ADV_PCI1710)  += adv_pci1710.o
 obj-$(CONFIG_COMEDI_ADV_PCI1720)   += adv_pci1720.o
 obj-$(CONFIG_COMEDI_ADV_PCI1723)   += adv_pci1723.o
 obj-$(CONFIG_COMEDI_ADV_PCI1724)   += adv_pci1724.o
+obj-$(CONFIG_COMEDI_ADV_PCI1760)   += adv_pci1760.o
 obj-$(CONFIG_COMEDI_ADV_PCI_DIO)   += adv_pci_dio.o
 obj-$(CONFIG_COMEDI_AMPLC_DIO200_PCI)  += amplc_dio200_pci.o
 obj-$(CONFIG_COMEDI_AMPLC_PC236_PCI)   += amplc_pci236.o
diff --git a/drivers/staging/comedi/drivers/adv_pci1760.c 
b/drivers/staging/comedi/drivers/adv_pci1760.c
new file mode 100644
index 000..8d71165
--- /dev/null
+++ b/drivers/staging/comedi/drivers/adv_pci1760.c
@@ -0,0 +1,432 @@
+/*
+ * COMEDI driver for the Advantech PCI-1760
+ * Copyright (C) 2015 H Hartley Sweeten 
+ *
+ * Based on the pci1760 support in the adv_pci_dio driver written by:
+ * Michal Dobes 
+ *
+ * COMEDI - Linux Control and Measurement Device Interface
+ * Copyright (C) 2000 David A. Schleef 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Driver: adv_pci1760
+ * Description: Advantech PCI-1760 Relay & Isolated Digital Input Card
+ * Devices: [Advantech] PCI-1760 (adv_pci1760)
+ * Author: H Hartley Sweeten 
+ * Updated: Mon, 09 Jan 2012 12:40:46 +
+ * Status: untested
+ *
+ * Configuration Options: not applicable, uses PCI auto config
+ */
+
+#include 
+

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

2015-11-12 Thread Vitaly Kuznetsov 
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+ #1053
...
[   90.800082] Call Trace:
[   90.800082]  [] __fput+0xc8/0x1f0
[   90.800082]  [] fput+0xe/0x10
[   90.800082]  [] task_work_run+0x73/0x90
[   90.800082]  [] do_exit+0x335/0xa90
[   90.800082]  [] do_group_exit+0x3f/0xc0
[   90.800082]  [] get_signal+0x25e/0x5e0
[   90.800082]  [] do_signal+0x28/0x580
[   90.800082]  [] ? finish_task_switch+0xa6/0x180
[   90.800082]  [] ? __schedule+0x28f/0x870
[   90.800082]  [] ? hvt_op_read+0x12a/0x140 [hv_utils]
[   90.800082]  [] ? wake_atomic_t_function+0x70/0x70
...
[   90.800082] RIP  [] module_put+0x16/0x90
[   90.800082]  RSP 
[   95.734261] ---[ end trace 0e09af6a6294a668 ]---

The problem is that hvutil_transport_destroy() which does misc_deregister()
freeing the appropriate device is reachable by two paths: module unload
and from util_remove(). While module unload path is protected by .owner in
struct file_operations util_remove() path is not. Freeing the device while
someone holds an open fd for it is a show stopper.

In general, it is not possible to revoke an fd from all users so the only
way to solve the issue is to defer freeing the hvutil_transport structure
asking the daemon to exit gracefully by responding -EBADF to all
operations on unload.

Patch 1 fixes an unrelated issue I spotted, patch 2 renames outmsg_lock to
'lock' as we're gonna use it to protect test-and-set operations on 'mode',
patch 3 introduces HVUTIL_TRANSPORT_DESTROY mode of operation, patch 4
fixes the issue itself.

Patches are rebased on previously sent Olaf's fixes.

Vitaly Kuznetsov (4):
  Drivers: hv: utils: fix memory leak on on_msg() failure
  Drivers: hv: utils: rename outmsg_lock
  Drivers: hv: utils: introduce HVUTIL_TRANSPORT_DESTROY mode
  Drivers: hv: utils: fix crash when device is removed from host side

 drivers/hv/hv_utils_transport.c | 110 +++-
 drivers/hv/hv_utils_transport.h |   3 +-
 2 files changed, 88 insertions(+), 25 deletions(-)

-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Vitaly Kuznetsov 
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 insertions(+), 8 deletions(-)

diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 1d20451..5cce2d2 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -27,11 +27,11 @@ static struct list_head hvt_list = LIST_HEAD_INIT(hvt_list);
 
 static void hvt_reset(struct hvutil_transport *hvt)
 {
-   mutex_lock(>outmsg_lock);
+   mutex_lock(>lock);
kfree(hvt->outmsg);
hvt->outmsg = NULL;
hvt->outmsg_len = 0;
-   mutex_unlock(>outmsg_lock);
+   mutex_unlock(>lock);
if (hvt->on_reset)
hvt->on_reset();
 }
@@ -47,7 +47,7 @@ static ssize_t hvt_op_read(struct file *file, char __user 
*buf,
if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0))
return -EINTR;
 
-   mutex_lock(>outmsg_lock);
+   mutex_lock(>lock);
if (!hvt->outmsg) {
ret = -EAGAIN;
goto out_unlock;
@@ -68,7 +68,7 @@ static ssize_t hvt_op_read(struct file *file, char __user 
*buf,
hvt->outmsg_len = 0;
 
 out_unlock:
-   mutex_unlock(>outmsg_lock);
+   mutex_unlock(>lock);
return ret;
 }
 
@@ -197,7 +197,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt, 
void *msg, int len)
return ret;
}
/* HVUTIL_TRANSPORT_CHARDEV */
-   mutex_lock(>outmsg_lock);
+   mutex_lock(>lock);
if (hvt->outmsg) {
/* Previous message wasn't received */
ret = -EFAULT;
@@ -211,7 +211,7 @@ int hvutil_transport_send(struct hvutil_transport *hvt, 
void *msg, int len)
} else
ret = -ENOMEM;
 out_unlock:
-   mutex_unlock(>outmsg_lock);
+   mutex_unlock(>lock);
return ret;
 }
 
@@ -242,7 +242,7 @@ struct hvutil_transport *hvutil_transport_init(const char 
*name,
hvt->mdev.fops = >fops;
 
init_waitqueue_head(>outmsg_q);
-   mutex_init(>outmsg_lock);
+   mutex_init(>lock);
 
spin_lock(_list_lock);
list_add(>list, _list);
diff --git a/drivers/hv/hv_utils_transport.h b/drivers/hv/hv_utils_transport.h
index 314c76c..bff4c92 100644
--- a/drivers/hv/hv_utils_transport.h
+++ b/drivers/hv/hv_utils_transport.h
@@ -38,7 +38,7 @@ struct hvutil_transport {
u8 *outmsg; /* message to the userspace */
int outmsg_len; /* its length */
wait_queue_head_t outmsg_q; /* poll/read wait queue */
-   struct mutex outmsg_lock;   /* protects outmsg */
+   struct mutex lock;  /* protects struct members */
 };
 
 struct hvutil_transport *hvutil_transport_init(const char *name,
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Vitaly Kuznetsov 
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 contexts now we need to use
a proper locking.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/hv_utils_transport.c | 69 -
 drivers/hv/hv_utils_transport.h |  1 +
 2 files changed, 56 insertions(+), 14 deletions(-)

diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 5cce2d2..984cba5 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -27,11 +27,9 @@ static struct list_head hvt_list = LIST_HEAD_INIT(hvt_list);
 
 static void hvt_reset(struct hvutil_transport *hvt)
 {
-   mutex_lock(>lock);
kfree(hvt->outmsg);
hvt->outmsg = NULL;
hvt->outmsg_len = 0;
-   mutex_unlock(>lock);
if (hvt->on_reset)
hvt->on_reset();
 }
@@ -44,10 +42,17 @@ static ssize_t hvt_op_read(struct file *file, char __user 
*buf,
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
-   if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0))
+   if (wait_event_interruptible(hvt->outmsg_q, hvt->outmsg_len > 0 ||
+hvt->mode != HVUTIL_TRANSPORT_CHARDEV))
return -EINTR;
 
mutex_lock(>lock);
+
+   if (hvt->mode == HVUTIL_TRANSPORT_DESTROY) {
+   ret = -EBADF;
+   goto out_unlock;
+   }
+
if (!hvt->outmsg) {
ret = -EAGAIN;
goto out_unlock;
@@ -85,6 +90,9 @@ static ssize_t hvt_op_write(struct file *file, const char 
__user *buf,
if (IS_ERR(inmsg))
return PTR_ERR(inmsg);
 
+   if (hvt->mode == HVUTIL_TRANSPORT_DESTROY)
+   return -EBADF;
+
if (hvt->on_msg(inmsg, count))
ret = -EFAULT;
kfree(inmsg);
@@ -99,6 +107,10 @@ static unsigned int hvt_op_poll(struct file *file, 
poll_table *wait)
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
poll_wait(file, >outmsg_q, wait);
+
+   if (hvt->mode == HVUTIL_TRANSPORT_DESTROY)
+   return -EBADF;
+
if (hvt->outmsg_len > 0)
return POLLIN | POLLRDNORM;
 
@@ -108,26 +120,39 @@ static unsigned int hvt_op_poll(struct file *file, 
poll_table *wait)
 static int hvt_op_open(struct inode *inode, struct file *file)
 {
struct hvutil_transport *hvt;
+   int ret = 0;
+   bool issue_reset = false;
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
-   /*
-* Switching to CHARDEV mode. We switch bach to INIT when device
-* gets released.
-*/
-   if (hvt->mode == HVUTIL_TRANSPORT_INIT)
+   mutex_lock(>lock);
+
+   if (hvt->mode == HVUTIL_TRANSPORT_DESTROY) {
+   ret = -EBADF;
+   } else if (hvt->mode == HVUTIL_TRANSPORT_INIT) {
+   /*
+* Switching to CHARDEV mode. We switch bach to INIT when
+* device gets released.
+*/
hvt->mode = HVUTIL_TRANSPORT_CHARDEV;
+   }
else if (hvt->mode == HVUTIL_TRANSPORT_NETLINK) {
/*
 * We're switching from netlink communication to using char
 * device. Issue the reset first.
 */
-   hvt_reset(hvt);
+   issue_reset = true;
hvt->mode = HVUTIL_TRANSPORT_CHARDEV;
-   } else
-   return -EBUSY;
+   } else {
+   ret = -EBUSY;
+   }
 
-   return 0;
+   if (issue_reset)
+   hvt_reset(hvt);
+
+   mutex_unlock(>lock);
+
+   return ret;
 }
 
 static int hvt_op_release(struct inode *inode, struct file *file)
@@ -136,12 +161,15 @@ static int hvt_op_release(struct inode *inode, struct 
file *file)
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
-   hvt->mode = HVUTIL_TRANSPORT_INIT;
+   mutex_lock(>lock);
+   if (hvt->mode != HVUTIL_TRANSPORT_DESTROY)
+   hvt->mode = HVUTIL_TRANSPORT_INIT;
/*
 * Cleanup message buffers to avoid spurious messages when the daemon
 * connects back.
 */
hvt_reset(hvt);
+   mutex_unlock(>lock);
 
return 0;
 }
@@ -168,6 +196,7 @@ static void hvt_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)
 * Switching to NETLINK mode. Switching to CHARDEV happens when someone
 * opens the device.
 */
+   mutex_lock(>lock);
if (hvt->mode == HVUTIL_TRANSPORT_INIT)
hvt->mode = HVUTIL_TRANSPORT_NETLINK;
 
@@ -175,6 +204,7 @@ static void hvt_cn_callback(struct cn_msg *msg, struct 
netlink_skb_parms *nsp)

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

2015-11-12 Thread Vitaly Kuznetsov 
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 b/drivers/hv/hv_utils_transport.c
index 24b2766..1d20451 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -77,6 +77,7 @@ static ssize_t hvt_op_write(struct file *file, const char 
__user *buf,
 {
struct hvutil_transport *hvt;
u8 *inmsg;
+   ssize_t ret = count;
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
@@ -85,10 +86,10 @@ static ssize_t hvt_op_write(struct file *file, const char 
__user *buf,
return PTR_ERR(inmsg);
 
if (hvt->on_msg(inmsg, count))
-   return -EFAULT;
+   ret = -EFAULT;
kfree(inmsg);
 
-   return count;
+   return ret;
 }
 
 static unsigned int hvt_op_poll(struct file *file, poll_table *wait)
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Vitaly Kuznetsov 
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]  [] do_signal+0x28/0x580
[   90.800082]  [] ? finish_task_switch+0xa6/0x180
[   90.800082]  [] ? __schedule+0x28f/0x870
[   90.800082]  [] ? hvt_op_read+0x12a/0x140 [hv_utils]
...

The problem is that hvutil_transport_destroy() which does misc_deregister()
freeing the appropriate device is reachable by two paths: module unload
and from util_remove(). While module unload path is protected by .owner in
struct file_operations util_remove() path is not. Freeing the device while
someone holds an open fd for it is a show stopper.

In general, it is not possible to revoke an fd from all users so the only
way to solve the issue is to defer freeing the hvutil_transport structure.

Signed-off-by: Vitaly Kuznetsov 
---
 drivers/hv/hv_utils_transport.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/hv/hv_utils_transport.c b/drivers/hv/hv_utils_transport.c
index 984cba5..174c72a 100644
--- a/drivers/hv/hv_utils_transport.c
+++ b/drivers/hv/hv_utils_transport.c
@@ -155,13 +155,22 @@ static int hvt_op_open(struct inode *inode, struct file 
*file)
return ret;
 }
 
+static void hvt_transport_free(struct hvutil_transport *hvt)
+{
+   misc_deregister(>mdev);
+   kfree(hvt->outmsg);
+   kfree(hvt);
+}
+
 static int hvt_op_release(struct inode *inode, struct file *file)
 {
struct hvutil_transport *hvt;
+   int mode_old;
 
hvt = container_of(file->f_op, struct hvutil_transport, fops);
 
mutex_lock(>lock);
+   mode_old = hvt->mode;
if (hvt->mode != HVUTIL_TRANSPORT_DESTROY)
hvt->mode = HVUTIL_TRANSPORT_INIT;
/*
@@ -171,6 +180,9 @@ static int hvt_op_release(struct inode *inode, struct file 
*file)
hvt_reset(hvt);
mutex_unlock(>lock);
 
+   if (mode_old == HVUTIL_TRANSPORT_DESTROY)
+   hvt_transport_free(hvt);
+
return 0;
 }
 
@@ -304,17 +316,25 @@ err_free_hvt:
 
 void hvutil_transport_destroy(struct hvutil_transport *hvt)
 {
+   int mode_old;
+
mutex_lock(>lock);
+   mode_old = hvt->mode;
hvt->mode = HVUTIL_TRANSPORT_DESTROY;
wake_up_interruptible(>outmsg_q);
mutex_unlock(>lock);
 
+   /*
+* In case we were in 'chardev' mode we still have an open fd so we
+* have to defer freeing the device. Netlink interface can be freed
+* now.
+*/
spin_lock(_list_lock);
list_del(>list);
spin_unlock(_list_lock);
if (hvt->cn_id.idx > 0 && hvt->cn_id.val > 0)
cn_del_callback(>cn_id);
-   misc_deregister(>mdev);
-   kfree(hvt->outmsg);
-   kfree(hvt);
+
+   if (mode_old != HVUTIL_TRANSPORT_CHARDEV)
+   hvt_transport_free(hvt);
 }
-- 
2.4.3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Luick, Dean 
> -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 variables 
> declared
> but they are never used - the compiler has short-circuited the rest of the
> function.  Will not the compiler complain about unused variables in those 
> cases?
> That is the situation I was trying to avoid.
> 
> Try it and see (hint, I don't think so...)

I tested this - you are correct, no compiler warnings.  Looks like my fears 
were premature.  The failure logic will be inverted per Dan's comments.


Dean
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Vitaly Kuznetsov 
"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 here? In
that can maybe we can just switch to spin_lock()/spin_unlock()?

>
> Signed-off-by: Dexuan Cui 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  drivers/hv/channel_mgmt.c |   12 ++--
>  drivers/hv/connection.c   |7 +++
>  drivers/hv/hyperv_vmbus.h |2 +-
>  3 files changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 9c9da3a..d013171 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -206,9 +206,9 @@ void hv_process_channel_removal(struct vmbus_channel 
> *channel, u32 relid)
>   }
>
>   if (channel->primary_channel == NULL) {
> - spin_lock_irqsave(_connection.channel_lock, flags);
> + mutex_lock(_connection.channel_mutex);
>   list_del(>listentry);
> - spin_unlock_irqrestore(_connection.channel_lock, flags);
> + mutex_unlock(_connection.channel_mutex);
>
>   primary_channel = channel;
>   } else {
> @@ -253,7 +253,7 @@ static void vmbus_process_offer(struct vmbus_channel 
> *newchannel)
>   unsigned long flags;
>
>   /* Make sure this is a new offer */
> - spin_lock_irqsave(_connection.channel_lock, flags);
> + mutex_lock(_connection.channel_mutex);
>
>   list_for_each_entry(channel, _connection.chn_list, listentry) {
>   if (!uuid_le_cmp(channel->offermsg.offer.if_type,
> @@ -269,7 +269,7 @@ static void vmbus_process_offer(struct vmbus_channel 
> *newchannel)
>   list_add_tail(>listentry,
> _connection.chn_list);
>
> - spin_unlock_irqrestore(_connection.channel_lock, flags);
> + mutex_unlock(_connection.channel_mutex);
>
>   if (!fnew) {
>   /*
> @@ -341,9 +341,9 @@ static void vmbus_process_offer(struct vmbus_channel 
> *newchannel)
>  err_deq_chan:
>   vmbus_release_relid(newchannel->offermsg.child_relid);
>
> - spin_lock_irqsave(_connection.channel_lock, flags);
> + mutex_lock(_connection.channel_mutex);
>   list_del(>listentry);
> - spin_unlock_irqrestore(_connection.channel_lock, flags);
> + mutex_unlock(_connection.channel_mutex);
>
>   if (newchannel->target_cpu != get_cpu()) {
>   put_cpu();
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index 4fc2e88..521f48e 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -146,7 +146,7 @@ int vmbus_connect(void)
>   spin_lock_init(_connection.channelmsg_lock);
>
>   INIT_LIST_HEAD(_connection.chn_list);
> - spin_lock_init(_connection.channel_lock);
> + mutex_init(_connection.channel_mutex);
>
>   /*
>* Setup the vmbus event connection for channel interrupt
> @@ -282,11 +282,10 @@ struct vmbus_channel *relid2channel(u32 relid)
>  {
>   struct vmbus_channel *channel;
>   struct vmbus_channel *found_channel  = NULL;
> - unsigned long flags;
>   struct list_head *cur, *tmp;
>   struct vmbus_channel *cur_sc;
>
> - spin_lock_irqsave(_connection.channel_lock, flags);
> + mutex_lock(_connection.channel_mutex);
>   list_for_each_entry(channel, _connection.chn_list, listentry) {
>   if (channel->offermsg.child_relid == relid) {
>   found_channel = channel;
> @@ -305,7 +304,7 @@ struct vmbus_channel *relid2channel(u32 relid)
>   }
>   }
>   }
> - spin_unlock_irqrestore(_connection.channel_lock, flags);
> + mutex_unlock(_connection.channel_mutex);
>
>   return found_channel;
>  }
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 64950d8..0af6dce 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -688,7 +688,7 @@ struct vmbus_connection {
>
>   /* List of channels */
>   struct list_head chn_list;
> - spinlock_t channel_lock;
> + struct mutex channel_mutex;
>
>   struct workqueue_struct *work_queue;
>  };

-- 
  Vitaly
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Arnd Bergmann 
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 this patch and the previous one(14/20) which works fine.
> I cannot find the problem in this patch at the moment. I will see if I can 
> find something,
> and I'd appreciate if you would help with it.
> 

I've looked at it some more, but didn't find anything obvious, here are some
possible things I found:


> > -struct wilc_hif_func wilc_hif_sdio = {
> > -   sdio_init,
> > -   sdio_deinit,
> > -   sdio_read_reg,
> > -   sdio_write_reg,
> > -   sdio_read,
> > -   sdio_write,
> > -   sdio_sync,
> > -   sdio_clear_int,
> > -   sdio_read_int,
> > -   sdio_clear_int_ext,
> > -   sdio_read_size,
> > -   sdio_write,
> > -   sdio_read,
> > -   sdio_sync_ext,
> > -
> > -   sdio_set_max_speed,
> > -   sdio_set_default_speed,
> > +const struct wilc_hif_func wilc_hif_sdio = {
> > +   .hif_init = sdio_init,
> > +   .hif_deinit = sdio_deinit,
> > +   .hif_read_reg = sdio_read_reg,
> > +   .hif_write_reg = sdio_write_reg,
> > +   .hif_block_rx = sdio_read,
> > +   .hif_block_tx = sdio_write,
> > +   .hif_sync = sdio_sync,
> > +   .hif_clear_int = sdio_clear_int,
> > +   .hif_read_int = sdio_read_int,
> > +   .hif_clear_int_ext = sdio_clear_int_ext,
> > +   .hif_read_size = sdio_read_size,
> > +   .hif_block_rx_ext = sdio_write,
> > +   .hif_block_tx_ext = sdio_read,
> > +   .hif_sync_ext = sdio_sync_ext,
> > +   .hif_set_max_bus_speed = sdio_set_max_speed,
> > +   .hif_set_default_bus_speed = sdio_set_default_speed,
> >   };

If the callbacks are not in the same order here, something could
in theory go wrong. I've tried to verify them by inspection and
could not find anything here, but you can try reverting this part.

> > memset((void *)_wlan, 0, sizeof(wilc_wlan_dev_t));
> > g_wlan.io_type = wilc->io_type;
> > -
> > -#ifdef WILC_SDIO
> > -   if (!wilc_hif_sdio.hif_init(wilc, wilc_debug)) {
> > -   ret = -EIO;
> > -   goto _fail_;
> > -   }
> > -   memcpy((void *)_wlan.hif_func, _hif_sdio,
> > -  sizeof(struct wilc_hif_func));
> > -#else
> > -   if (!wilc_hif_spi.hif_init(wilc, wilc_debug)) {
> > +   g_wlan.hif_func = *wilc->ops;
> > +   if (!g_wlan.hif_func.hif_init(wilc, wilc_debug)) {
> > ret = -EIO;
> > goto _fail_;
> > }
> > -   memcpy((void *)_wlan.hif_func, _hif_spi,
> > -  sizeof(struct wilc_hif_func));
> > -#endif

This is the most likely part I found:

doing an assigment instead of memcpy should not make a difference,
but my new version also called init after copying over the
operations rather than before. This seemed to be the correct
order when I did it, but it is a change in behavior that might
cause problems if some code relies on the hif_func structure
to be empty at the time that hif_init is called.

Arnd
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread glen lee 



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 start and it fails.
I double check this patch and the previous one(14/20) which works fine.
I cannot find the problem in this patch at the moment. I will see if I can find 
something,
and I'd appreciate if you would help with it.


I've looked at it some more, but didn't find anything obvious, here are some
possible things I found:



-struct wilc_hif_func wilc_hif_sdio = {
-   sdio_init,
-   sdio_deinit,
-   sdio_read_reg,
-   sdio_write_reg,
-   sdio_read,
-   sdio_write,
-   sdio_sync,
-   sdio_clear_int,
-   sdio_read_int,
-   sdio_clear_int_ext,
-   sdio_read_size,
-   sdio_write,
-   sdio_read,
-   sdio_sync_ext,
-
-   sdio_set_max_speed,
-   sdio_set_default_speed,
+const struct wilc_hif_func wilc_hif_sdio = {
+   .hif_init = sdio_init,
+   .hif_deinit = sdio_deinit,
+   .hif_read_reg = sdio_read_reg,
+   .hif_write_reg = sdio_write_reg,
+   .hif_block_rx = sdio_read,
+   .hif_block_tx = sdio_write,
+   .hif_sync = sdio_sync,
+   .hif_clear_int = sdio_clear_int,
+   .hif_read_int = sdio_read_int,
+   .hif_clear_int_ext = sdio_clear_int_ext,
+   .hif_read_size = sdio_read_size,
+   .hif_block_rx_ext = sdio_write,
+   .hif_block_tx_ext = sdio_read,


Hi arnd,

I found this. These should be like this. It works fine.
+   .hif_block_tx_ext = sdio_write,
+   .hif_block_rx_ext = sdio_read,

also, wilc_hif_spi need to be fixed together like this.
+   .hif_block_tx_ext = _wilc_spi_write,
+   .hif_block_rx_ext = _wilc_spi_read,

Thank you for all the patches.

regards,
glen lee


+   .hif_sync_ext = sdio_sync_ext,
+   .hif_set_max_bus_speed = sdio_set_max_speed,
+   .hif_set_default_bus_speed = sdio_set_default_speed,
   };

If the callbacks are not in the same order here, something could
in theory go wrong. I've tried to verify them by inspection and
could not find anything here, but you can try reverting this part.


memset((void *)_wlan, 0, sizeof(wilc_wlan_dev_t));
g_wlan.io_type = wilc->io_type;
-
-#ifdef WILC_SDIO
-   if (!wilc_hif_sdio.hif_init(wilc, wilc_debug)) {
-   ret = -EIO;
-   goto _fail_;
-   }
-   memcpy((void *)_wlan.hif_func, _hif_sdio,
-  sizeof(struct wilc_hif_func));
-#else
-   if (!wilc_hif_spi.hif_init(wilc, wilc_debug)) {
+   g_wlan.hif_func = *wilc->ops;
+   if (!g_wlan.hif_func.hif_init(wilc, wilc_debug)) {
ret = -EIO;
goto _fail_;
}
-   memcpy((void *)_wlan.hif_func, _hif_spi,
-  sizeof(struct wilc_hif_func));
-#endif

This is the most likely part I found:

doing an assigment instead of memcpy should not make a difference,
but my new version also called init after copying over the
operations rather than before. This seemed to be the correct
order when I did it, but it is a change in behavior that might
cause problems if some code relies on the hif_func structure
to be empty at the time that hif_init is called.

Arnd


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Dennis Dalessandro 

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: Dennis Dalessandro 
+int snoop_send_dma_handler(struct hfi1_qp *qp, struct hfi1_pkt_state *ps,



-   pr_alert("Snooping/Capture of  Send DMA Packets Is Not
Supported!\n");
+   pr_alert("Snooping/Capture of Send DMA Packets Is Not Supported!\n");


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 function.

See: http://www.spinics.net/lists/linux-rdma/msg30244.html

-Denny
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Dexuan Cui 
> 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 Srinivasan 
> Subject: 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 :-)

Sorry, I should have written a better changelog. :-)

 > Or are you trying to say we don't need to disable interrupts here? In

Yes.
Here we try to protect vmbus_connection.chn_list and the related
channel pointer (see relid2channel()) from being updated in parallel.

The parallel paths, e.g., vmbus_process_offer() and
vmbus_onoffer_rescind(), are in process context and no irq context is
involved, so we don't need disable interrupts at all.

> that can maybe we can just switch to spin_lock()/spin_unlock()?

Switching to mutex actually makes preparation for a later patch (which
will be posted to LKML once this pachset is accepted):

Drivers: hv: vmbus: add an API vmbus_hvsock_device_unregister()
https://github.com/dcui/linux/commit/185afe8394a9bdae2be11ee1ea2a38d05e373025
(on branch decui/vmsock_1020)

For a vmsock socket connection, the host and the guest can be closing
the connection at the same time.

When the host tries to close the connection, a rescind offer is received
in the VM.

When the guest tries to close the connection, a new vmbus API
vmbus_hvsock_device_unregister(channel) is invoked, so
vmbus_hvsock_device_unregister() -> vmbus_device_unregister() is
invoked and this can be running in parallel with
vmbus_onoffer_rescind() -> vmbus_device_unregister().

The issue of "vmbus_onoffer_rescind () -> relid2channel()" is:
it returns a channel pointer without the spinlock held, so actually
there is no real protection for the channel pointer.

So IMO we need to serialize vmbus_onoffer_rescind() and
vmbus_hvsock_device_unregister().
Here I use mutex (rather than spinlock) because the critical section
can sleep, due to vmbus_device_unregister().

Thanks,
-- Dexuan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Or Gerlitz 
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 function.
> See: http://www.spinics.net/lists/linux-rdma/msg30244.html

my comment was general
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Ian Abbott 

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 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_6527.c 
b/drivers/staging/comedi/drivers/ni_6527.c
index 62a817e..b340b98 100644
--- a/drivers/staging/comedi/drivers/ni_6527.c
+++ b/drivers/staging/comedi/drivers/ni_6527.c
@@ -42,24 +42,24 @@
  #define NI6527_DO_REG(x)  (0x03 + (x))
  #define NI6527_ID_REG 0x06
  #define NI6527_CLR_REG0x07
-#define NI6527_CLR_EDGE(1 << 3)
-#define NI6527_CLR_OVERFLOW(1 << 2)
-#define NI6527_CLR_FILT(1 << 1)
-#define NI6527_CLR_INTERVAL(1 << 0)
+#define NI6527_CLR_EDGEBIT(3)
+#define NI6527_CLR_OVERFLOWBIT(2)
+#define NI6527_CLR_FILTBIT(1)
+#define NI6527_CLR_INTERVALBIT(0)
  #define NI6527_CLR_IRQS   (NI6527_CLR_EDGE | 
NI6527_CLR_OVERFLOW)
  #define NI6527_CLR_RESET_FILT (NI6527_CLR_FILT | NI6527_CLR_INTERVAL)
  #define NI6527_FILT_INTERVAL_REG(x)   (0x08 + (x))
  #define NI6527_FILT_ENA_REG(x)(0x0c + (x))
  #define NI6527_STATUS_REG 0x14
-#define NI6527_STATUS_IRQ  (1 << 2)
-#define NI6527_STATUS_OVERFLOW (1 << 1)
-#define NI6527_STATUS_EDGE (1 << 0)
+#define NI6527_STATUS_IRQ  BIT(2)
+#define NI6527_STATUS_OVERFLOW BIT(1)
+#define NI6527_STATUS_EDGE BIT(0)
  #define NI6527_CTRL_REG   0x15
-#define NI6527_CTRL_FALLING(1 << 4)
-#define NI6527_CTRL_RISING (1 << 3)
-#define NI6527_CTRL_IRQ(1 << 2)
-#define NI6527_CTRL_OVERFLOW   (1 << 1)
-#define NI6527_CTRL_EDGE   (1 << 0)
+#define NI6527_CTRL_FALLINGBIT(4)
+#define NI6527_CTRL_RISING BIT(3)
+#define NI6527_CTRL_IRQBIT(2)
+#define NI6527_CTRL_OVERFLOW   BIT(1)
+#define NI6527_CTRL_EDGE   BIT(0)
  #define NI6527_CTRL_DISABLE_IRQS  0
  #define NI6527_CTRL_ENABLE_IRQS   (NI6527_CTRL_FALLING | \
 NI6527_CTRL_RISING | \



Again, the column with the macro values is a bit misaligned.  Could you 
fix it please?


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Ian Abbott 

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 deletions(-)

diff --git a/drivers/staging/comedi/drivers/cb_pcidda.c 
b/drivers/staging/comedi/drivers/cb_pcidda.c
index b00a36a..ccb37d1 100644
--- a/drivers/staging/comedi/drivers/cb_pcidda.c
+++ b/drivers/staging/comedi/drivers/cb_pcidda.c
@@ -51,13 +51,13 @@

  /* DAC registers */
  #define CB_DDA_DA_CTRL_REG0x00   /* D/A Control Register  */
-#define CB_DDA_DA_CTRL_SU  (1 << 0)   /*  Simultaneous update  */
-#define CB_DDA_DA_CTRL_EN  (1 << 1)   /*  Enable specified DAC */
+#define CB_DDA_DA_CTRL_SU  BIT(0)   /*  Simultaneous update  */
+#define CB_DDA_DA_CTRL_EN  BIT(1)   /*  Enable specified DAC */
  #define CB_DDA_DA_CTRL_DAC(x) ((x) << 2) /*  Specify DAC channel  */
  #define CB_DDA_DA_CTRL_RANGE2V5   (0 << 6)   /*  2.5V range   
*/
  #define CB_DDA_DA_CTRL_RANGE5V(2 << 6)   /*  5V range 
*/
  #define CB_DDA_DA_CTRL_RANGE10V   (3 << 6)   /*  10V range
*/
-#define CB_DDA_DA_CTRL_UNIP(1 << 8)   /*  Unipolar range   */
+#define CB_DDA_DA_CTRL_UNIPBIT(8)   /*  Unipolar range   */

  #define DACALIBRATION14   /*  D/A CALIBRATION REGISTER 1 */
  /* write bits */



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Ian Abbott 

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 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/comedi/drivers/comedi_parport.c 
b/drivers/staging/comedi/drivers/comedi_parport.c
index 15a4093..1bf8ddc 100644
--- a/drivers/staging/comedi/drivers/comedi_parport.c
+++ b/drivers/staging/comedi/drivers/comedi_parport.c
@@ -75,8 +75,8 @@
  #define PARPORT_DATA_REG  0x00
  #define PARPORT_STATUS_REG0x01
  #define PARPORT_CTRL_REG  0x02
-#define PARPORT_CTRL_IRQ_ENA   (1 << 4)
-#define PARPORT_CTRL_BIDIR_ENA (1 << 5)
+#define PARPORT_CTRL_IRQ_ENA   BIT(4)
+#define PARPORT_CTRL_BIDIR_ENA BIT(5)

  static int parport_data_reg_insn_bits(struct comedi_device *dev,
  struct comedi_subdevice *s,



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Fabio Estevam 
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
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Ian Abbott 

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 changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/comedi/drivers/pcmmio.c 
b/drivers/staging/comedi/drivers/pcmmio.c
index 10472e6..f7ec224 100644
--- a/drivers/staging/comedi/drivers/pcmmio.c
+++ b/drivers/staging/comedi/drivers/pcmmio.c
@@ -84,25 +84,25 @@
  #define PCMMIO_AI_LSB_REG 0x00
  #define PCMMIO_AI_MSB_REG 0x01
  #define PCMMIO_AI_CMD_REG 0x02
-#define PCMMIO_AI_CMD_SE   (1 << 7)
-#define PCMMIO_AI_CMD_ODD_CHAN (1 << 6)
+#define PCMMIO_AI_CMD_SE   BIT(7)
+#define PCMMIO_AI_CMD_ODD_CHAN BIT(6)
  #define PCMMIO_AI_CMD_CHAN_SEL(x) (((x) & 0x3) << 4)
  #define PCMMIO_AI_CMD_RANGE(x)(((x) & 0x3) << 2)
-#define PCMMIO_RESOURCE_REG0x02
+#define PCMMIO_RESOURCE_REG0x02
  #define PCMMIO_RESOURCE_IRQ(x)(((x) & 0xf) << 0)
  #define PCMMIO_AI_STATUS_REG  0x03
-#define PCMMIO_AI_STATUS_DATA_READY(1 << 7)
-#define PCMMIO_AI_STATUS_DATA_DMA_PEND (1 << 6)
-#define PCMMIO_AI_STATUS_CMD_DMA_PEND  (1 << 5)
-#define PCMMIO_AI_STATUS_IRQ_PEND  (1 << 4)
-#define PCMMIO_AI_STATUS_DATA_DRQ_ENA  (1 << 2)
-#define PCMMIO_AI_STATUS_REG_SEL   (1 << 3)
-#define PCMMIO_AI_STATUS_CMD_DRQ_ENA   (1 << 1)
-#define PCMMIO_AI_STATUS_IRQ_ENA   (1 << 0)
+#define PCMMIO_AI_STATUS_DATA_READYBIT(7)
+#define PCMMIO_AI_STATUS_DATA_DMA_PEND BIT(6)
+#define PCMMIO_AI_STATUS_CMD_DMA_PEND  BIT(5)
+#define PCMMIO_AI_STATUS_IRQ_PEND  BIT(4)
+#define PCMMIO_AI_STATUS_DATA_DRQ_ENA  BIT(2)
+#define PCMMIO_AI_STATUS_REG_SEL   BIT(3)
+#define PCMMIO_AI_STATUS_CMD_DRQ_ENA   BIT(1)
+#define PCMMIO_AI_STATUS_IRQ_ENA   BIT(0)
  #define PCMMIO_AI_RES_ENA_REG 0x03
-#define PCMMIO_AI_RES_ENA_CMD_REG_ACCESS   (0 << 3)
-#define PCMMIO_AI_RES_ENA_AI_RES_ACCESS(1 << 3)
-#define PCMMIO_AI_RES_ENA_DIO_RES_ACCESS   (1 << 4)
+#define PCMMIO_AI_RES_ENA_CMD_REG_ACCESS   0
+#define PCMMIO_AI_RES_ENA_AI_RES_ACCESSBIT(3)
+#define PCMMIO_AI_RES_ENA_DIO_RES_ACCESS   BIT(4)
  #define PCMMIO_AI_2ND_ADC_OFFSET  0x04

  #define PCMMIO_AO_LSB_REG 0x08
@@ -125,14 +125,14 @@
  #define PCMMIO_AO_CMD_CHAN_SEL(x) (((x) & 0x03) << 1)
  #define PCMMIO_AO_CMD_CHAN_SEL_ALL(0x0f << 0)
  #define PCMMIO_AO_STATUS_REG  0x0b
-#define PCMMIO_AO_STATUS_DATA_READY(1 << 7)
-#define PCMMIO_AO_STATUS_DATA_DMA_PEND (1 << 6)
-#define PCMMIO_AO_STATUS_CMD_DMA_PEND  (1 << 5)
-#define PCMMIO_AO_STATUS_IRQ_PEND  (1 << 4)
-#define PCMMIO_AO_STATUS_DATA_DRQ_ENA  (1 << 2)
-#define PCMMIO_AO_STATUS_REG_SEL   (1 << 3)
-#define PCMMIO_AO_STATUS_CMD_DRQ_ENA   (1 << 1)
-#define PCMMIO_AO_STATUS_IRQ_ENA   (1 << 0)
+#define PCMMIO_AO_STATUS_DATA_READYBIT(7)
+#define PCMMIO_AO_STATUS_DATA_DMA_PEND BIT(6)
+#define PCMMIO_AO_STATUS_CMD_DMA_PEND  BIT(5)
+#define PCMMIO_AO_STATUS_IRQ_PEND  BIT(4)
+#define PCMMIO_AO_STATUS_DATA_DRQ_ENA  BIT(2)
+#define PCMMIO_AO_STATUS_REG_SEL   BIT(3)
+#define PCMMIO_AO_STATUS_CMD_DRQ_ENA   BIT(1)
+#define PCMMIO_AO_STATUS_IRQ_ENA   BIT(0)
  #define PCMMIO_AO_RESOURCE_ENA_REG0x0b
  #define PCMMIO_AO_2ND_DAC_OFFSET  0x04




The macro values used to be more-or-less nicely aligned in a column, but 
now they are not so nicely aligned.  Could you add or delete TABs as 
needed to line them up?  Remember, tab stops are every 8 spaces.


--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Ian Abbott 

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 changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_65xx.c 
b/drivers/staging/comedi/drivers/ni_65xx.c
index 800d574..251117b 100644
--- a/drivers/staging/comedi/drivers/ni_65xx.c
+++ b/drivers/staging/comedi/drivers/ni_65xx.c
@@ -68,25 +68,25 @@
  /* Non-recurring Registers (8-bit except where noted) */
  #define NI_65XX_ID_REG0x00
  #define NI_65XX_CLR_REG   0x01
-#define NI_65XX_CLR_WDOG_INT   (1 << 6)
-#define NI_65XX_CLR_WDOG_PING  (1 << 5)
-#define NI_65XX_CLR_WDOG_EXP   (1 << 4)
-#define NI_65XX_CLR_EDGE_INT   (1 << 3)
-#define NI_65XX_CLR_OVERFLOW_INT   (1 << 2)
+#define NI_65XX_CLR_WDOG_INT   BIT(6)
+#define NI_65XX_CLR_WDOG_PING  BIT(5)
+#define NI_65XX_CLR_WDOG_EXP   BIT(4)
+#define NI_65XX_CLR_EDGE_INT   BIT(3)
+#define NI_65XX_CLR_OVERFLOW_INT   BIT(2)
  #define NI_65XX_STATUS_REG0x02
-#define NI_65XX_STATUS_WDOG_INT(1 << 5)
-#define NI_65XX_STATUS_FALL_EDGE   (1 << 4)
-#define NI_65XX_STATUS_RISE_EDGE   (1 << 3)
-#define NI_65XX_STATUS_INT (1 << 2)
-#define NI_65XX_STATUS_OVERFLOW_INT(1 << 1)
-#define NI_65XX_STATUS_EDGE_INT(1 << 0)
+#define NI_65XX_STATUS_WDOG_INTBIT(5)
+#define NI_65XX_STATUS_FALL_EDGE   BIT(4)
+#define NI_65XX_STATUS_RISE_EDGE   BIT(3)
+#define NI_65XX_STATUS_INT BIT(2)
+#define NI_65XX_STATUS_OVERFLOW_INTBIT(1)
+#define NI_65XX_STATUS_EDGE_INTBIT(0)
  #define NI_65XX_CTRL_REG  0x03
-#define NI_65XX_CTRL_WDOG_ENA  (1 << 5)
-#define NI_65XX_CTRL_FALL_EDGE_ENA (1 << 4)
-#define NI_65XX_CTRL_RISE_EDGE_ENA (1 << 3)
-#define NI_65XX_CTRL_INT_ENA   (1 << 2)
-#define NI_65XX_CTRL_OVERFLOW_ENA  (1 << 1)
-#define NI_65XX_CTRL_EDGE_ENA  (1 << 0)
+#define NI_65XX_CTRL_WDOG_ENA  BIT(5)
+#define NI_65XX_CTRL_FALL_EDGE_ENA BIT(4)
+#define NI_65XX_CTRL_RISE_EDGE_ENA BIT(3)
+#define NI_65XX_CTRL_INT_ENA   BIT(2)
+#define NI_65XX_CTRL_OVERFLOW_ENA  BIT(1)
+#define NI_65XX_CTRL_EDGE_ENA  BIT(0)
  #define NI_65XX_REV_REG   0x04 /* 32-bit */
  #define NI_65XX_FILTER_REG0x08 /* 32-bit */
  #define NI_65XX_RTSI_ROUTE_REG0x0c /* 16-bit */
@@ -94,24 +94,24 @@
  #define NI_65XX_RTSI_WDOG_REG 0x10 /* 16-bit */
  #define NI_65XX_RTSI_TRIG_REG 0x12 /* 16-bit */
  #define NI_65XX_AUTO_CLK_SEL_REG  0x14 /* PXI-6528 only */
-#define NI_65XX_AUTO_CLK_SEL_STATUS(1 << 1)
-#define NI_65XX_AUTO_CLK_SEL_DISABLE   (1 << 0)
+#define NI_65XX_AUTO_CLK_SEL_STATUSBIT(1)
+#define NI_65XX_AUTO_CLK_SEL_DISABLE   BIT(0)
  #define NI_65XX_WDOG_CTRL_REG 0x15
-#define NI_65XX_WDOG_CTRL_ENA  (1 << 0)
+#define NI_65XX_WDOG_CTRL_ENA  BIT(0)
  #define NI_65XX_RTSI_CFG_REG  0x16
-#define NI_65XX_RTSI_CFG_RISE_SENSE(1 << 2)
-#define NI_65XX_RTSI_CFG_FALL_SENSE(1 << 1)
-#define NI_65XX_RTSI_CFG_SYNC_DETECT   (1 << 0)
+#define NI_65XX_RTSI_CFG_RISE_SENSEBIT(2)
+#define NI_65XX_RTSI_CFG_FALL_SENSEBIT(1)
+#define NI_65XX_RTSI_CFG_SYNC_DETECT   BIT(0)
  #define NI_65XX_WDOG_STATUS_REG   0x17
-#define NI_65XX_WDOG_STATUS_EXP(1 << 0)
+#define NI_65XX_WDOG_STATUS_EXPBIT(0)
  #define NI_65XX_WDOG_INTERVAL_REG 0x18 /* 32-bit */

  /* Recurring port registers (8-bit) */
  #define NI_65XX_PORT(x)   ((x) * 0x10)
  #define NI_65XX_IO_DATA_REG(x)(0x40 + NI_65XX_PORT(x))
  #define NI_65XX_IO_SEL_REG(x) (0x41 + NI_65XX_PORT(x))
-#define NI_65XX_IO_SEL_OUTPUT  (0 << 0)
-#define NI_65XX_IO_SEL_INPUT   (1 << 0)
+#define NI_65XX_IO_SEL_OUTPUT  0
+#define NI_65XX_IO_SEL_INPUT   BIT(0)
  #define NI_65XX_RISE_EDGE_ENA_REG(x)  (0x42 + NI_65XX_PORT(x))
  #define NI_65XX_FALL_EDGE_ENA_REG(x)  (0x43 + NI_65XX_PORT(x))
  #define NI_65XX_FILTER_ENA(x) (0x44 + NI_65XX_PORT(x))
@@ -613,7 +613,7 @@ static int ni_65xx_intr_insn_config(struct comedi_device 
*dev,

  /* ripped from mite.h and mite_setup2() to avoid mite dependency */
  #define MITE_IODWBSR  0xc0 /* IO Device Window Base Size Register */
-#define WENAB  (1 << 7) /* window enable */
+#define WENAB  BIT(7) /* window enable */

  static int ni_65xx_mite_init(struct pci_dev *pcidev)
  {



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

2015-11-12 Thread KY Srinivasan 


> -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 ;
> Haiyang Zhang ; Vitaly Kuznetsov
> 
> Subject: Re: [PATCH 1/1] drivers/hv: correct tsc page sequence invalid value
> 
> On 11/02/2015 10:42 PM, KY Srinivasan wrote:
> >
> >> -Original Message-
> >> From: Denis V. Lunev [mailto:d...@openvz.org]
> >> Sent: Monday, November 2, 2015 3:34 AM
> >> Cc: rka...@virtuozzo.com; de...@linuxdriverproject.org; linux-
> >> ker...@vger.kernel.org; Andrey Smetanin ;
> KY
> >> Srinivasan ; Haiyang Zhang
> >> ; Vitaly Kuznetsov ;
> >> Denis V. Lunev 
> >> Subject: [PATCH 1/1] drivers/hv: correct tsc page sequence invalid value
> >>
> >> From: Andrey Smetanin 
> >>
> >> Hypervisor Top Level Functional Specification v3/4 says
> >> that TSC page sequence value = -1(0x) is used to
> >> indicate that TSC page no longer reliable source of reference
> >> timer. Unfortunately, we found that Windows Hyper-V guest
> >> side implementation uses sequence value = 0 to indicate
> >> that Tsc page no longer valid. This is clearly visible
> >> inside Windows 2012R2 ntoskrnl.exe HvlGetReferenceTime()
> >> function dissassembly:
> >>
> >> HvlGetReferenceTime proc near
> >>   xchgax, ax
> >> loc_1401C3132:
> >>   mov rax, cs:HvlpReferenceTscPage
> >>   mov r9d, [rax]
> >>   testr9d, r9d
> >>   jz  short loc_1401C3176
> >>   rdtsc
> >>   mov rcx, cs:HvlpReferenceTscPage
> >>   shl rdx, 20h
> >>   or  rdx, rax
> >>   mov rax, [rcx+8]
> >>   mov rcx, cs:HvlpReferenceTscPage
> >>   mov r8, [rcx+10h]
> >>   mul rdx
> >>   mov rax, cs:HvlpReferenceTscPage
> >>   add rdx, r8
> >>   mov ecx, [rax]
> >>   cmp ecx, r9d
> >>   jnz short loc_1401C3132
> >>   jmp short loc_1401C3184
> >> loc_1401C3176:
> >>   mov ecx, 4020h
> >>   rdmsr
> >>   shl rdx, 20h
> >>   or  rdx, rax
> >> loc_1401C3184:
> >>   mov rax, rdx
> >>   retn
> >> HvlGetReferenceTime endp
> >>
> >> This patch aligns Tsc page invalid sequence value with
> >> Windows Hyper-V guest implementation which is more
> >> compatible with both Hyper-V hypervisor and KVM hypervisor.
> >>
> >> Signed-off-by: Andrey Smetanin 
> >> CC: "K. Y. Srinivasan" 
> > Thanks Andrey; the Hyper-V team will be updating the Hyper-V
> documentation.
> >
> > Acked-by: K. Y. Srinivasan 
> >
> > Regards,
> >
> > K. Y
> K.Y.,
> 
> can you pls clarify the state of this patch? It is a bit unclear
> to me whether it is applied or not.

I will be submitting this shortly.

> 
> By the way, I also do not see the following patch
> "drivers/hv: cleanup synic msrs if vmbus connect failed"
> as applied in the Linux-next. You have promised to resend
> it will correct author.

It was resent on October 29. It is in Greg's queue.

Regards,

K. Y
> 
> Thank you in advance,
>  Den
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

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

2015-11-12 Thread Denis V. Lunev 

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 Smetanin ;
Haiyang Zhang ; Vitaly Kuznetsov

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

On 11/02/2015 10:42 PM, KY Srinivasan wrote:

-Original Message-
From: Denis V. Lunev [mailto:d...@openvz.org]
Sent: Monday, November 2, 2015 3:34 AM
Cc: rka...@virtuozzo.com; de...@linuxdriverproject.org; linux-
ker...@vger.kernel.org; Andrey Smetanin ;

KY

Srinivasan ; Haiyang Zhang
; Vitaly Kuznetsov ;
Denis V. Lunev 
Subject: [PATCH 1/1] drivers/hv: correct tsc page sequence invalid value

From: Andrey Smetanin 

Hypervisor Top Level Functional Specification v3/4 says
that TSC page sequence value = -1(0x) is used to
indicate that TSC page no longer reliable source of reference
timer. Unfortunately, we found that Windows Hyper-V guest
side implementation uses sequence value = 0 to indicate
that Tsc page no longer valid. This is clearly visible
inside Windows 2012R2 ntoskrnl.exe HvlGetReferenceTime()
function dissassembly:

HvlGetReferenceTime proc near
   xchgax, ax
loc_1401C3132:
   mov rax, cs:HvlpReferenceTscPage
   mov r9d, [rax]
   testr9d, r9d
   jz  short loc_1401C3176
   rdtsc
   mov rcx, cs:HvlpReferenceTscPage
   shl rdx, 20h
   or  rdx, rax
   mov rax, [rcx+8]
   mov rcx, cs:HvlpReferenceTscPage
   mov r8, [rcx+10h]
   mul rdx
   mov rax, cs:HvlpReferenceTscPage
   add rdx, r8
   mov ecx, [rax]
   cmp ecx, r9d
   jnz short loc_1401C3132
   jmp short loc_1401C3184
loc_1401C3176:
   mov ecx, 4020h
   rdmsr
   shl rdx, 20h
   or  rdx, rax
loc_1401C3184:
   mov rax, rdx
   retn
HvlGetReferenceTime endp

This patch aligns Tsc page invalid sequence value with
Windows Hyper-V guest implementation which is more
compatible with both Hyper-V hypervisor and KVM hypervisor.

Signed-off-by: Andrey Smetanin 
CC: "K. Y. Srinivasan" 

Thanks Andrey; the Hyper-V team will be updating the Hyper-V

documentation.

Acked-by: K. Y. Srinivasan 

Regards,

K. Y

K.Y.,

can you pls clarify the state of this patch? It is a bit unclear
to me whether it is applied or not.

I will be submitting this shortly.


By the way, I also do not see the following patch
"drivers/hv: cleanup synic msrs if vmbus connect failed"
as applied in the Linux-next. You have promised to resend
it will correct author.

It was resent on October 29. It is in Greg's queue.

Regards,

K. Y

Thank you in advance,
  Den

thank you very much for this update :)

Den
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel