Re: [PATCH V2 1/2] scsi: storvsc: Install the storvsc specific timeout handler for FC devices
On Wed, Jan 27, 2016 at 06:22:44PM -0800, K. Y. Srinivasan wrote: > The default timeout routine used for FC transport is not > suitable for FC devices managed by storvsc since FC devices > managed by storvsc driver do not have an rport associated > with them. Use the time out handler used for SCSI devices > for FC devices as well. > > Signed-off-by: K. Y. Srinivasan > Reviewed-by: Alex Ng > Tested-by: Vivek Yadav > --- > drivers/scsi/storvsc_drv.c |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c > index 41c115c..622f64a 100644 > --- a/drivers/scsi/storvsc_drv.c > +++ b/drivers/scsi/storvsc_drv.c > @@ -42,6 +42,7 @@ > #include > #include > #include > +#include > > /* > * All wire protocol details (storage protocol between the guest and the > host) > @@ -1770,6 +1771,11 @@ static int __init storvsc_drv_init(void) > fc_transport_template = fc_attach_transport(&fc_transport_functions); > if (!fc_transport_template) > return -ENODEV; > + > + /* > + * Install Hyper-V specific timeout handler. > + */ > + fc_transport_template->eh_timed_out = storvsc_eh_timed_out; > #endif > > ret = vmbus_driver_register(&storvsc_drv); > -- > 1.7.4.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH V2 2/2] scsi: storvsc: Use the specified target ID in device lookup
On Wed, Jan 27, 2016 at 06:22:45PM -0800, K. Y. Srinivasan wrote:
> The current code assumes that there is only one target in device lookup.
> Fix this bug. This will alow us to correctly handle hot reomoval of LUNs.
>
> Signed-off-by: K. Y. Srinivasan
> Reviewed-by: Alex Ng
> Tested-by: Vivek Yadav
> ---
> V2: Made lun and target_id unsigned 8 bit entities - Hannes Reinecke
>
>
> drivers/scsi/storvsc_drv.c | 10 +-
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> index 622f64a..132b168 100644
> --- a/drivers/scsi/storvsc_drv.c
> +++ b/drivers/scsi/storvsc_drv.c
> @@ -478,19 +478,18 @@ struct hv_host_device {
> struct storvsc_scan_work {
> struct work_struct work;
> struct Scsi_Host *host;
> - uint lun;
> + u8 lun;
> + u8 tgt_id;
> };
>
> static void storvsc_device_scan(struct work_struct *work)
> {
> struct storvsc_scan_work *wrk;
> - uint lun;
> struct scsi_device *sdev;
>
> wrk = container_of(work, struct storvsc_scan_work, work);
> - lun = wrk->lun;
>
> - sdev = scsi_device_lookup(wrk->host, 0, 0, lun);
> + sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun);
> if (!sdev)
> goto done;
> scsi_rescan_device(&sdev->sdev_gendev);
> @@ -541,7 +540,7 @@ static void storvsc_remove_lun(struct work_struct *work)
> if (!scsi_host_get(wrk->host))
> goto done;
>
> - sdev = scsi_device_lookup(wrk->host, 0, 0, wrk->lun);
> + sdev = scsi_device_lookup(wrk->host, 0, wrk->tgt_id, wrk->lun);
>
> if (sdev) {
> scsi_remove_device(sdev);
> @@ -941,6 +940,7 @@ static void storvsc_handle_error(struct vmscsi_request
> *vm_srb,
>
> wrk->host = host;
> wrk->lun = vm_srb->lun;
> + wrk->tgt_id = vm_srb->target_id;
> INIT_WORK(&wrk->work, process_err_fn);
> schedule_work(&wrk->work);
> }
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
On Wed, Jan 27, 2016 at 01:41:03PM -0800, Greg Hackmann wrote: > On 01/27/2016 12:25 PM, Gustavo Padovan wrote: > Is there a value in keeping the abi unchanged? > If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read. > >>> > >>>None from me. I'll look where we can improve the ABI. > > Android has existing clients of the current ABI. Thankfully they're all > contained in system services like SurfaceFlinger, since end-user apps don't > get direct access to fence fds. > > As long the ABI breaks don't remove functionality we depend on, we can wrap > around them in our userspace libsync. I'd rather not have to do that, but > it's a price I'm willing to pay to get this moved out of staging. > > >> - struct sync_file_info_data::fence_info is of type __u8 yet it is "a > >>fence_info struct for every fence in the sync_file". Thus shouldn't > >>one use "struct fence_info" as the type ? > > > >Agreed. But I'm currently thinking if we really should keep this ioctl. > > > > Gustavo > > > > I'm not seeing any consumers of driver_data in our tree. OTOH completely > getting rid of the ioctl would be a problem, since SurfaceFlinger depends on > the timestamp information for its own bookkeeping. If we remove driver_data (and len is superflous too), then I think we should also make the master struct use common ioctl pattern: - Add a num_fences field or similar that the kernel fills out. - Make pt_info an __u64 pointer instead of a variable-length array (and length) - ioctl payload sizes are somewhat limited. This way the interface is future-proofed for truly patalogical number of fences (which surface flinger won't do, but could happen in server/opencl/media workloads I'd imagine). And I think driver_data really shouldn't be there, it makes things complicated with the array of variable-sized objects, and generic userspace can't really use it - for debug output we already have obj/driver_name per fence point, which I think is good enough. Would that be ok for you from the Android side if Gustavo also provides a patch to update libsync? I don't think the ABI is fundamentally broken, but this light cleanup would be nice. Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since polling is supported, but not really an issue imo either. If we're totally lazy we could implement SYNC_WAIT internally using poll and shave off a few lines of the implementation. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/6] continuous regeneration of finite samples
On 27/01/16 21:28, Spencer E. Olson wrote: These patches implement a proposal to very slightly extend the interpretation of cmd->stop_arg when cmd->stop_src == TRIG_NONE. Normally, for output subdevices, when the user specifies cmd->stop_src == TRIG_NONE, the device should continuously output data that must also be continually fed by the user via either a mmap/comedi_mark_buffer_written or an write(...) operation. The intent of this proposal is to also allow a user to have a specific buffer repeated as-is indefinitely. This is accomplished by the user specifying the length of the fixed buffer via cmd->stop_arg > 0. It should be noted that cmd->stop_arg in this case must also be <= the size of the available dma buffer. The prior behavior is maintained when cmd->stop_arg == 0, which is also enforced by the *_cmdtest functions for many, if not all output devices. All devices which do not implement this new behavior should simply continue to enforce cmd->stop_arg == 0 in *_cmdtest functions. These patches implement the extended interpretation of cmd->stop_arg >0 for when cmd->stop_src==TRIG_NONE for National Instruments m/e-series devices only that are based on the ni_mio_common driver. Currently, these changes only apply to analog output and cdio output devices. This patches also implement suggestions made by Ian Abbot, namely: (1) all patches were run through checkpatch.pl and fixed accordingly to comply with coding standards, (2) all block comments were changed to comply with comments beginning on the line after the /* delimiter, (3) dev_warn use in drivers/mite.c as used during debugging was changed to dev_dbg, and (4) mite.c logic statements were made simpler and more robust following Ian's suggestions. ** ** v2 changes ** ** (5) Prior PATCH 2/3 (staging: comedi: ni_mio_comon: adds finite regeneration to AO output) was split into 4 patches (current PATCHES [2-5]/6) that keep the changes a bit more atomic. Spencer E. Olson (6): staging: comedi: mite: enable continuous regeneration of finite samples staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_reset staging: comedi: ni_mio_common: make more bits in ao_cmd1 reg be stateful staging: comedi: ni_mio_common: Cleans up/clarifies ni_ao_cmd staging: comedi: ni_mio_common: adds finite regeneration to AO output staging: comedi: ni_mio_common: add finite regeneration to dio output drivers/staging/comedi/drivers/mite.c | 72 +++- drivers/staging/comedi/drivers/mite.h | 3 + drivers/staging/comedi/drivers/ni_mio_common.c | 573 ++--- 3 files changed, 479 insertions(+), 169 deletions(-) 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 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Wednesday, January 27, 2016 10:03 PM > To: KY Srinivasan ; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > martin.peter...@oracle.com; h...@suse.de > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild > test > robot > > On Wed, 2016-01-27 at 23:29 -0800, K. Y. Srinivasan wrote: > > tree: https://na01.safelinks.protection.outlook.com/?url=https%3a%2 > > f%2fgit.kernel.org%2fpub%2fscm%2flinux%2fkernel%2fgit%2ftorvalds%2fli > > > nux.git&data=01%7c01%7ckys%40microsoft.com%7ce2e0622715844b79ad71 > 08d3 > > > 2796ec3c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ubr4GbBaNS > %2ftO > > z%2buJBk0CL9N0UNG9x2TidLgy6Yovg4%3d master > > head: 03c21cb775a313f1ff19be59c5d02df3e3526471 > > commit: dac582417bc449b1f7f572d3f1dd9d23eec15cc9 storvsc: Properly > > support Fibre Channel devices > > date: 3 weeks ago > > config: x86_64-randconfig-s3-01281016 (attached as .config) > > reproduce: > > git checkout dac582417bc449b1f7f572d3f1dd9d23eec15cc9 > > # save the attached .config to linux build tree > > make ARCH=x86_64 > > > > All errors (new ones prefixed by >>): > > > >drivers/built-in.o: In function `storvsc_remove': > > > > storvsc_drv.c:(.text+0x213af7): undefined reference to > > > > `fc_remove_host' > >drivers/built-in.o: In function `storvsc_drv_init': > > > > storvsc_drv.c:(.init.text+0xcbcc): undefined reference to > > > > `fc_attach_transport' > > > > storvsc_drv.c:(.init.text+0xcc06): undefined reference to > > > > `fc_release_transport' > >drivers/built-in.o: In function `storvsc_drv_exit': > > > > storvsc_drv.c:(.exit.text+0x123c): undefined reference to > > > > `fc_release_transport' > > > > With this commit, the storvsc driver depends on FC atttributes. Make > > this > > dependency explicit. > > > > Signed-off-by: K. Y. Srinivasan > > Reported-by: Fengguang Wu > > --- > > drivers/scsi/Kconfig |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig > > index 64eed87..24365c3 100644 > > --- a/drivers/scsi/Kconfig > > +++ b/drivers/scsi/Kconfig > > @@ -594,6 +594,7 @@ config XEN_SCSI_FRONTEND > > config HYPERV_STORAGE > > tristate "Microsoft Hyper-V virtual storage driver" > > depends on SCSI && HYPERV > > + depends on SCSI_FC_ATTRS > > default HYPERV > > help > > Select this option to enable the Hyper-V virtual storage > > driver. > > OK, so I thought Hannes requested that you not make the hyperv driver > depend on the FC attrs and you said you would ... has this changed? Since 99% of the code would be identical, Hannes agreed that it would not be good to have a separate FC driver. Given that, this is the only option we have. Regards, K. Y > > James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Wed, Jan 27, K. Y. Srinivasan wrote: > + depends on SCSI_FC_ATTRS I think 'depends' instead of 'select' will cause HYPERV_STORAGE to disapepar during make oldconfig if SCSI_FC_ATTRS was not set before. Not sure what the policy of 'depends' vs. 'select' actually is. If SCSI_FC_ATTRS is supposed to be a library kind of thing then 'select' might be the correct way. Olaf ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message- > From: Olaf Hering [mailto:o...@aepfle.de] > Sent: Thursday, January 28, 2016 7:56 AM > To: KY Srinivasan > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > martin.peter...@oracle.com; h...@suse.de > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild > test > robot > > On Wed, Jan 27, K. Y. Srinivasan wrote: > > > + depends on SCSI_FC_ATTRS > > I think 'depends' instead of 'select' will cause HYPERV_STORAGE to > disapepar during make oldconfig if SCSI_FC_ATTRS was not set before. > Not sure what the policy of 'depends' vs. 'select' actually is. If > SCSI_FC_ATTRS is supposed to be a library kind of thing then 'select' > might be the correct way. The current build issue is because the Hyper-V storage is configured to be built with the kernel while the SCSI_FC_AATRS is configured as a module. This patch fixes that issue. I too am not sure what the policy of using "depends" vs " select" is. James, what would be your recommendation here. Regards, K. Y > > Olaf ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
On Thu, 2016-01-28 at 19:07 +, KY Srinivasan wrote: > > > -Original Message- > > From: Olaf Hering [mailto:o...@aepfle.de] > > Sent: Thursday, January 28, 2016 7:56 AM > > To: KY Srinivasan > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > de...@linuxdriverproject.org; oher...@suse.com; > > jbottom...@parallels.com; h...@infradead.org; > > linux-s...@vger.kernel.org; > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > > martin.peter...@oracle.com; h...@suse.de > > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported > > by kbuild test > > robot > > > > On Wed, Jan 27, K. Y. Srinivasan wrote: > > > > > + depends on SCSI_FC_ATTRS > > > > I think 'depends' instead of 'select' will cause HYPERV_STORAGE to > > disapepar during make oldconfig if SCSI_FC_ATTRS was not set > > before. > > Not sure what the policy of 'depends' vs. 'select' actually is. > > If > > SCSI_FC_ATTRS is supposed to be a library kind of thing then > > 'select' > > might be the correct way. > > The current build issue is because the Hyper-V storage is configured > to be built with > the kernel while the SCSI_FC_AATRS is configured as a module. This > patch fixes that issue. > I too am not sure what the policy of using "depends" vs " select" is. > James, what would be your recommendation here. Oh, you don't care if FC_ATTRS are enabled, but if they are you need to exclude the case where storvsc is built in but FC_ATTRS is a module? This is the accepted way of doing it: depends on m || SCSI_FC_ATTRS != m James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild test robot
> -Original Message- > From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] > Sent: Thursday, January 28, 2016 11:22 AM > To: KY Srinivasan ; Olaf Hering > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; oher...@suse.com; > jbottom...@parallels.com; h...@infradead.org; linux-s...@vger.kernel.org; > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > martin.peter...@oracle.com; h...@suse.de > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported by kbuild > test > robot > > On Thu, 2016-01-28 at 19:07 +, KY Srinivasan wrote: > > > > > -Original Message- > > > From: Olaf Hering [mailto:o...@aepfle.de] > > > Sent: Thursday, January 28, 2016 7:56 AM > > > To: KY Srinivasan > > > Cc: gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; > > > de...@linuxdriverproject.org; oher...@suse.com; > > > jbottom...@parallels.com; h...@infradead.org; > > > linux-s...@vger.kernel.org; > > > a...@canonical.com; vkuzn...@redhat.com; jasow...@redhat.com; > > > martin.peter...@oracle.com; h...@suse.de > > > Subject: Re: [PATCH 1/1] scsi: storvsc: Fix a build issue reported > > > by kbuild test > > > robot > > > > > > On Wed, Jan 27, K. Y. Srinivasan wrote: > > > > > > > + depends on SCSI_FC_ATTRS > > > > > > I think 'depends' instead of 'select' will cause HYPERV_STORAGE to > > > disapepar during make oldconfig if SCSI_FC_ATTRS was not set > > > before. > > > Not sure what the policy of 'depends' vs. 'select' actually is. > > > If > > > SCSI_FC_ATTRS is supposed to be a library kind of thing then > > > 'select' > > > might be the correct way. > > > > The current build issue is because the Hyper-V storage is configured > > to be built with > > the kernel while the SCSI_FC_AATRS is configured as a module. This > > patch fixes that issue. > > I too am not sure what the policy of using "depends" vs " select" is. > > James, what would be your recommendation here. > > Oh, you don't care if FC_ATTRS are enabled, but if they are you need to > exclude the case where storvsc is built in but FC_ATTRS is a module? > This is the accepted way of doing it: > > depends on m || SCSI_FC_ATTRS != m Thanks James, I will resubmit this patch with the change you have recommended. K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Missed patch for hfi1 from Gregs tree.
Doug, The following patch was not accepted by Greg and does not appear in patchworks https://marc.info/?l=linux-rdma&m=145090416416677&w=2 We have this patch and can resubmit it for patchworks but I don't want to get in the way of the original author. Julia, Would you mind if we resubmit it to get it in the queue for Doug? Otherwise could you resubmit? Note: the staging/rdma tree is now being maintained by Doug Ledford (linux-rdma). Thanks, Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Missed patch for hfi1 from Gregs tree.
On Thu, Jan 28, 2016 at 03:30:23PM -0500, ira.weiny wrote: > Doug, > > The following patch was not accepted by Greg and does not appear in patchworks > > https://marc.info/?l=linux-rdma&m=145090416416677&w=2 I have a whole stack of staging patches I have yet to get through. Over 1000 at the moment, they will be gotten to eventually... greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Missed patch for hfi1 from Gregs tree.
On Thu, 28 Jan 2016, gre...@linuxfoundation.org wrote: > On Thu, Jan 28, 2016 at 03:30:23PM -0500, ira.weiny wrote: > > Doug, > > > > The following patch was not accepted by Greg and does not appear in > > patchworks > > > > https://marc.info/?l=linux-rdma&m=145090416416677&w=2 > > I have a whole stack of staging patches I have yet to get through. Over > 1000 at the moment, they will be gotten to eventually... > > greg k-h Should I resubmit? julia ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Missed patch for hfi1 from Gregs tree.
On Thu, Jan 28, 2016 at 09:52:09PM +0100, Julia Lawall wrote: > > > On Thu, 28 Jan 2016, gre...@linuxfoundation.org wrote: > > > On Thu, Jan 28, 2016 at 03:30:23PM -0500, ira.weiny wrote: > > > Doug, > > > > > > The following patch was not accepted by Greg and does not appear in > > > patchworks > > > > > > https://marc.info/?l=linux-rdma&m=145090416416677&w=2 > > > > I have a whole stack of staging patches I have yet to get through. Over > > 1000 at the moment, they will be gotten to eventually... Greg, As we agreed to here: http://www.spinics.net/lists/linux-rdma/msg31782.html Doug has taken over the staging/rdma tree. I offered to help direct submissions to the staging tree to Doug/linux-rdma so that you would not have to worry about them. That is what I am doing here. Therefore, we would like Julia to resubmit to Doug so that we have 1 maintainer for this driver and the rdmavt/qib work. > > > > greg k-h > > Should I resubmit? Yes please resubmit to Doug/linux-rdma. Thanks, Ira ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH RESEND] staging: rdma: hfi1: diag: constify hfi1_filter_array structure
The hfi1_filter_array structure is never modified, so declare it as const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall
---
No change, resent to be picked up by Doug Ledford
drivers/staging/rdma/hfi1/diag.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rdma/hfi1/diag.c b/drivers/staging/rdma/hfi1/diag.c
index 0c88317..e41159f 100644
--- a/drivers/staging/rdma/hfi1/diag.c
+++ b/drivers/staging/rdma/hfi1/diag.c
@@ -257,7 +257,7 @@ static int hfi1_filter_ib_service_level(void *ibhdr, void
*packet_data,
static int hfi1_filter_ib_pkey(void *ibhdr, void *packet_data, void *value);
static int hfi1_filter_direction(void *ibhdr, void *packet_data, void *value);
-static struct hfi1_filter_array hfi1_filters[] = {
+static const struct hfi1_filter_array hfi1_filters[] = {
{ hfi1_filter_lid },
{ hfi1_filter_dlid },
{ hfi1_filter_mad_mgmt_class },
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH RESEND] staging: rdma: hfi1: diag: constify hfi1_filter_array structure
> Subject: [PATCH RESEND] staging: rdma: hfi1: diag: constify hfi1_filter_array > structure > > The hfi1_filter_array structure is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Thanks for the patch and for resubmitting. Acked-by: Mike Marciniszyn ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
NEW ARRIVALS, CISCO,CPU's,Memory, LAPTOP AND AVAYA
Dear Sir/Madam, Clean tested working pulls CPUs and QTYs in stock. 115 X X5650 65 X E5410 75 X X5660 145 X E5530 100 X E5645 40 X X5680 75 X X5690 Brand new sealed IP phones and QTYs in stock. 55 x CP-7937G 77 x CP-7942G 54 x CP-7945G 75 x CP-7962G .. 45 x Avaya 9630 65 x Avaya 9641 55 x Avaya 9640 All NIB. Here is our current stock list. SSD drives and 750 gig 2.5" sata drives We also have 250 x i5 dell 133 x HP 360 x Lenevo all grade A Here is the qty in stock for laptops 150 x E6500 Dell Latitude E6500 Core 2 Duo 2.80GHz T9600 4GB 160GB DVD+/-RW Win 7 60 x E6510 Dell Ltitude E6510. 15.6" Intel Core i5- M520 @ 2.40GHz. 4GB. 320GB DVD+/-RW Win 7 30 X 8530P HP EliteBook 8530p 15.4" Laptop 2.53GHz Core 2 Duo T9400, 4GB RAM, 160GB HDD, Win 100 x 8740W HP EliteBook 8740w 17" 2.4Ghz Core i5 6GB 250GB Win 7 Pr 45 x 8760W HP EliteBook 8760W 17.3" 2nd Gen Intel Core i7 2.70GHz 8GB 320GB Windows 7 Pro 50 x DELL 6520Dell latitude e6520 15.6" i5-2520M 2.5Ghz, 8GB Ram, 500GB HD Win 7 @ $115 120 x DELL 6420 Laptop Dell Latitude E6420 14" Intel Core i5 2.4Ghz 4GB RAM 250GB HDD DVD Win 7 150 x T410 Lenovo ThinkPad Laptop T410s 14.1" 2.40GHz Core i5 4GB RAM 160GB Win 7 180 x 8440P HP EliteBook 8440p 14" M520 Core i5 2.4GHz 4GB 250GB Win 7 Let me know if you're interested. We are very open to offers and willing to work with you to make sure that we have a deal. Thank You Barbara Johnson Laison Computech Inc 210 N Scoring Ave, Rialto California, 92376 Tel: +1-657-232-7047 Fax: +1-347-214-047 sa...@laisoncomputertech.us ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/12] staging: wilc1000: rename variable s32Error
Hi Leo,
On Thu, Jan 28, 2016 at 6:13 PM, Leo Kim wrote:
> This patch renames variable s32Error to result
> to avoid CamelCase naming convention.
> Also, remove the unused variable s32Error and replace with direct return.
>
> Signed-off-by: Leo Kim
> ---
> drivers/staging/wilc1000/coreconfigurator.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 2a4e324..88e5661 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -356,30 +356,29 @@ s32 wilc_parse_network_info(u8 *msg_buffer,
> tstrNetworkInfo **ret_network_info)
>
> s32 wilc_dealloc_network_info(tstrNetworkInfo *pstrNetworkInfo)
> {
> - s32 s32Error = 0;
> + s32 result = 0;
>
> if (pstrNetworkInfo) {
> if (pstrNetworkInfo->pu8IEs) {
> kfree(pstrNetworkInfo->pu8IEs);
> pstrNetworkInfo->pu8IEs = NULL;
I'm not sure it's necessary to set this to NULL here.
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> kfree(pstrNetworkInfo);
> pstrNetworkInfo = NULL;
Or this to NULL here.
Also, is the return value from this function actually checked? kfree()
can have NULL passed to it.
If the return value isn't checked, this entire function could be simplified to:
- - - - -
if (pstrNetworkInfo) {
kfree(pstrNetworkInfo->pu8IEs);
kfree(pstrNetworkInfo);
}
return 0;
- - - - -
Also, when tstrNetworkInfo structs are allocated, wouldn't the
allocating function fail if ->pu8IEs is NULL?
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> - return s32Error;
> + return result;
> }
>
> s32 wilc_parse_assoc_resp_info(u8 *pu8Buffer, u32 u32BufferLen,
>tstrConnectRespInfo **ppstrConnectRespInfo)
> {
> - s32 s32Error = 0;
> tstrConnectRespInfo *pstrConnectRespInfo = NULL;
> u16 u16AssocRespLen = 0;
> u8 *pu8IEs = NULL;
> @@ -408,27 +407,27 @@ s32 wilc_parse_assoc_resp_info(u8 *pu8Buffer, u32
> u32BufferLen,
>
> *ppstrConnectRespInfo = pstrConnectRespInfo;
>
> - return s32Error;
> + return 0;
> }
>
> s32 wilc_dealloc_assoc_resp_info(tstrConnectRespInfo *pstrConnectRespInfo)
> {
> - s32 s32Error = 0;
> + s32 result = 0;
All the comments above apply to this function as well.
>
> if (pstrConnectRespInfo) {
> if (pstrConnectRespInfo->pu8RespIEs) {
> kfree(pstrConnectRespInfo->pu8RespIEs);
> pstrConnectRespInfo->pu8RespIEs = NULL;
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> kfree(pstrConnectRespInfo);
> pstrConnectRespInfo = NULL;
>
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> - return s32Error;
> + return result;
> }
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Move wlan-ng out of staging?
Hi Greg, On Thu, Jan 28, 2016 at 10:32 AM, Greg KH wrote: > On Thu, Jan 28, 2016 at 10:28:38AM +1100, Julian Calaby wrote: >> Hi Greg, >> >> On Thu, Jan 28, 2016 at 10:07 AM, Greg KH wrote: >> > On Thu, Jan 28, 2016 at 09:48:16AM +1100, Julian Calaby wrote: >> >> Hi Glen, >> >> >> >> On Thu, Jan 28, 2016 at 5:27 AM, Kalle Valo wrote: >> >> > Dan Carpenter writes: >> >> > >> >> >> On Mon, Jan 25, 2016 at 01:16:56PM +0100, Ksenija Stanojević wrote: >> >> >>> Hi All, >> >> >>> >> >> >>> I'm helping Greg do a bit of cleanup in the staging tree, I noticed >> >> >>> that >> >> >>> wlan-ng driver is maybe ready to be moved out of staging. Are there >> >> >>> any TODO tasks left to do beside checkpatch.pl clean-up? >> >> > >> >> > For questions like this you should CC linux-wireless. >> >> > >> >> >> I happened to look through this code recently. It's terrible. >> >> > >> >> > And uses wireless extensions, yuck. There's a lot of work to get it into >> >> > reasonable shape, fixing checkpatch warnings will not be enough. >> >> >> >> On the same subject, the wilc1000 driver has taken some pretty big >> >> steps in the past few days, how far away do you think it is from >> >> graduating from staging? >> > >> > I have 221 patches in my to-apply queue to be merged for this driver, at >> > the very least, those need to be merged before anyone should review it >> > for graduation. That number also implies that there is still quite a >> > lot to be done, but I would not know for sure until that happens. >> >> I figured that was the case (there's a _lot_ of churn on that driver) >> however I've noticed the patches recently have swung away from being >> straight checkpatch / coding style cleanups towards feature additions >> and bug fixes, hence my question. > > Please feel free to audit it and let us know the details :) After looking at the latest round of patches, I take back my comment: it's not ready. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 08/12] staging: wilc1000: rename variable s32Error
Dear Julian
Thank you in your advises.
This patch subject is 'rename variables'.
This time, I hope the patch is applied.
I will be your positive advises change to next patch.
Thanks, BR
Leo
-Original Message-
From: Julian Calaby [mailto:julian.cal...@gmail.com]
Sent: Friday, January 29, 2016 9:55 AM
To: Kim, Leo
Cc: Greg KH ; de...@driverdev.osuosl.org;
linux-wireless ; Cho, Tony
; Lee, Glen ; Shin, Austin
; Park, Chris ; Abozaeid, Adham
; Ferre, Nicolas
Subject: Re: [PATCH 08/12] staging: wilc1000: rename variable s32Error
Hi Leo,
On Thu, Jan 28, 2016 at 6:13 PM, Leo Kim wrote:
> This patch renames variable s32Error to result to avoid CamelCase
> naming convention.
> Also, remove the unused variable s32Error and replace with direct return.
>
> Signed-off-by: Leo Kim
> ---
> drivers/staging/wilc1000/coreconfigurator.c | 19 +--
> 1 file changed, 9 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/staging/wilc1000/coreconfigurator.c
> b/drivers/staging/wilc1000/coreconfigurator.c
> index 2a4e324..88e5661 100644
> --- a/drivers/staging/wilc1000/coreconfigurator.c
> +++ b/drivers/staging/wilc1000/coreconfigurator.c
> @@ -356,30 +356,29 @@ s32 wilc_parse_network_info(u8 *msg_buffer,
> tstrNetworkInfo **ret_network_info)
>
> s32 wilc_dealloc_network_info(tstrNetworkInfo *pstrNetworkInfo) {
> - s32 s32Error = 0;
> + s32 result = 0;
>
> if (pstrNetworkInfo) {
> if (pstrNetworkInfo->pu8IEs) {
> kfree(pstrNetworkInfo->pu8IEs);
> pstrNetworkInfo->pu8IEs = NULL;
I'm not sure it's necessary to set this to NULL here.
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> kfree(pstrNetworkInfo);
> pstrNetworkInfo = NULL;
Or this to NULL here.
Also, is the return value from this function actually checked? kfree()
can have NULL passed to it.
If the return value isn't checked, this entire function could be simplified to:
- - - - -
if (pstrNetworkInfo) {
kfree(pstrNetworkInfo->pu8IEs);
kfree(pstrNetworkInfo);
}
return 0;
- - - - -
Also, when tstrNetworkInfo structs are allocated, wouldn't the
allocating function fail if ->pu8IEs is NULL?
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> - return s32Error;
> + return result;
> }
>
> s32 wilc_parse_assoc_resp_info(u8 *pu8Buffer, u32 u32BufferLen,
>tstrConnectRespInfo **ppstrConnectRespInfo)
> {
> - s32 s32Error = 0;
> tstrConnectRespInfo *pstrConnectRespInfo = NULL;
> u16 u16AssocRespLen = 0;
> u8 *pu8IEs = NULL;
> @@ -408,27 +407,27 @@ s32 wilc_parse_assoc_resp_info(u8 *pu8Buffer, u32
> u32BufferLen,
>
> *ppstrConnectRespInfo = pstrConnectRespInfo;
>
> - return s32Error;
> + return 0;
> }
>
> s32 wilc_dealloc_assoc_resp_info(tstrConnectRespInfo *pstrConnectRespInfo)
> {
> - s32 s32Error = 0;
> + s32 result = 0;
All the comments above apply to this function as well.
>
> if (pstrConnectRespInfo) {
> if (pstrConnectRespInfo->pu8RespIEs) {
> kfree(pstrConnectRespInfo->pu8RespIEs);
> pstrConnectRespInfo->pu8RespIEs = NULL;
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> kfree(pstrConnectRespInfo);
> pstrConnectRespInfo = NULL;
>
> } else {
> - s32Error = -EFAULT;
> + result = -EFAULT;
> }
>
> - return s32Error;
> + return result;
> }
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/12] staging: wilc1000: rename variable s32Error
Hi Leo, On Fri, Jan 29, 2016 at 1:55 PM, Kim, Leo wrote: > Dear Julian > > Thank you in your advises. > This patch subject is 'rename variables'. > This time, I hope the patch is applied. > > I will be your positive advises change to next patch. I should have been more clear, these were ideas for the next round of changes, not changes you should make to this patch. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: coding style cleanups for staging/panel driver
On Sat, Dec 19, 2015 at 12:50:56AM +0530, Bijosh Thykkoottathil wrote: > From: Bijosh Thykkoottathil > > This patch fixes coding style errors for staging/panel driver. > > Signed-off-by: Bijosh Thykkoottathil > --- > drivers/staging/panel/panel.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Someone sent this change before you, sorry :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: panel: fix the checkpatch issue
On Mon, Jan 18, 2016 at 12:40:48AM +0530, SirnamSwetha wrote: > Fix checkpatch.pl issue: > > WARNING: line over 80 characters > > CHECK: No space is necessary after a cast > > Signed-off-by: SirnamSwetha > --- > drivers/staging/panel/panel.c | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) Sorry, someone sent this before you did :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: Skein: Moved macros from skein_block.c to header file.
On Thu, Dec 17, 2015 at 12:46:14PM +0530, Sudip Mukherjee wrote: > On Mon, Dec 14, 2015 at 07:08:08PM -0500, Sanidhya Solanki wrote: > > The original code defined macros in the source code, making it > > harder to read. Moved them to the header file, as per the TODO file. > > > > Updated the TODO file. > > I think the TODO file should not be updated now. There are still some > macros in skein_block.c. I agree, it can't be removed just yet, this patch needs to be redone before I can take it. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: speakup: (coding style) Rewrite comparisons to NULL
On Thu, Nov 19, 2015 at 01:00:16PM +0100, Christian Colic wrote: > linux-ker...@vger.kernel.org > Bcc: > Subject: [PATCH] staging: speakup: (coding style) Rewrite comparisons to NULL > Reply-To: Why is this in the body of the email? I can't take this like this :( > > Rewrite comparisons to NULL so they dont show any checkpatch errors anymore. > "vc_cons[i].d != NULL" => "vc_cons[i].d" Please wrap your lines at 72 columns. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] staging: wilc1000: fix warnings for line over 80 characters
From: Chris Park
This patch fixes warnings reported by checkpatch.pl
for line over 80 characters
Signed-off-by: Chris Park
Signed-off-by: Leo Kim
---
drivers/staging/wilc1000/wilc_wlan.c | 33 -
drivers/staging/wilc1000/wilc_wlan.h | 3 ++-
2 files changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index 703dbe0..d0a499a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -113,7 +113,8 @@ static void wilc_wlan_txq_add_to_tail(struct net_device
*dev,
up(&wilc->txq_event);
}
-static int wilc_wlan_txq_add_to_head(struct wilc_vif *vif, struct txq_entry_t
*tqe)
+static int wilc_wlan_txq_add_to_head(struct wilc_vif *vif,
+struct txq_entry_t *tqe)
{
unsigned long flags;
struct wilc *wilc = vif->wilc;
@@ -695,8 +696,9 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
*txq_count)
acquire_bus(wilc, ACQUIRE_AND_WAKEUP);
counter = 0;
do {
- ret = wilc->hif_func->hif_read_reg(wilc,
WILC_HOST_TX_CTRL,
- ®);
+ ret = wilc->hif_func->hif_read_reg(wilc,
+ WILC_HOST_TX_CTRL,
+ ®);
if (!ret) {
wilc_debug(N_ERR, "[wilc txq]: fail can't read
reg vmm_tbl_entry..\n");
break;
@@ -728,8 +730,9 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
*txq_count)
break;
}
- ret = wilc->hif_func->hif_write_reg(wilc,
WILC_HOST_VMM_CTL,
- 0x2);
+ ret = wilc->hif_func->hif_write_reg(wilc,
+ WILC_HOST_VMM_CTL,
+ 0x2);
if (!ret) {
wilc_debug(N_ERR, "[wilc txq]: fail can't write
reg host_vmm_ctl..\n");
break;
@@ -1063,7 +1066,8 @@ void wilc_handle_isr(struct wilc *wilc)
}
EXPORT_SYMBOL_GPL(wilc_handle_isr);
-int wilc_wlan_firmware_download(struct wilc *wilc, const u8 *buffer, u32
buffer_size)
+int wilc_wlan_firmware_download(struct wilc *wilc, const u8 *buffer,
+ u32 buffer_size)
{
u32 offset;
u32 addr, size, size2, blksz;
@@ -1096,8 +1100,8 @@ int wilc_wlan_firmware_download(struct wilc *wilc, const
u8 *buffer, u32 buffer_
size2 = blksz;
memcpy(dma_buffer, &buffer[offset], size2);
- ret = wilc->hif_func->hif_block_tx(wilc, addr,
dma_buffer,
- size2);
+ ret = wilc->hif_func->hif_block_tx(wilc, addr,
+ dma_buffer, size2);
if (!ret)
break;
@@ -1233,7 +1237,8 @@ int wilc_wlan_stop(struct wilc *wilc)
}
do {
- ret = wilc->hif_func->hif_read_reg(wilc, WILC_GLB_RESET_0,
®);
+ ret = wilc->hif_func->hif_read_reg(wilc,
+ WILC_GLB_RESET_0, ®);
if (!ret) {
PRINT_ER("Error while reading reg\n");
release_bus(wilc, RELEASE_ALLOW_SLEEP);
@@ -1246,14 +1251,16 @@ int wilc_wlan_stop(struct wilc *wilc)
PRINT_D(GENERIC_DBG, "Bit 10 not reset : Retry %d\n",
timeout);
reg &= ~BIT(10);
- ret = wilc->hif_func->hif_write_reg(wilc,
WILC_GLB_RESET_0,
- reg);
+ ret = wilc->hif_func->hif_write_reg(wilc,
+ WILC_GLB_RESET_0,
+ reg);
timeout--;
} else {
PRINT_D(GENERIC_DBG, "Bit 10 reset after : Retry %d\n",
timeout);
- ret = wilc->hif_func->hif_read_reg(wilc,
WILC_GLB_RESET_0,
- ®);
+ ret = wilc->hif_func->hif_read_reg(wilc,
+ WILC_GLB_RESET_0,
+ ®);
if (!ret) {
PRINT_ER("Error while reading reg\n");
[PATCH 2/6] staging: wilc1000: remove useless log message
From: Chris Park
This patch remove useless log message in wilc_wlan.c file
Signed-off-by: Chris Park
Signed-off-by: Leo Kim
---
drivers/staging/wilc1000/wilc_wlan.c | 128 ++-
1 file changed, 22 insertions(+), 106 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index d0a499a..30e3c21 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -104,12 +104,9 @@ static void wilc_wlan_txq_add_to_tail(struct net_device
*dev,
wilc->txq_tail = tqe;
}
wilc->txq_entries += 1;
- PRINT_D(TX_DBG, "Number of entries in TxQ = %d\n", wilc->txq_entries);
spin_unlock_irqrestore(&wilc->txq_spinlock, flags);
- PRINT_D(TX_DBG, "Wake the txq_handling\n");
-
up(&wilc->txq_event);
}
@@ -137,12 +134,10 @@ static int wilc_wlan_txq_add_to_head(struct wilc_vif *vif,
wilc->txq_head = tqe;
}
wilc->txq_entries += 1;
- netdev_dbg(vif->ndev, "Number of entries in TxQ = %d\n",
wilc->txq_entries);
spin_unlock_irqrestore(&wilc->txq_spinlock, flags);
up(&wilc->txq_add_to_head_cs);
up(&wilc->txq_event);
- netdev_dbg(vif->ndev, "Wake up the txq_handler\n");
return 0;
}
@@ -188,7 +183,6 @@ static inline int add_tcp_session(u32 src_prt, u32 dst_prt,
u32 seq)
ack_session_info[tcp_session].dst_port = dst_prt;
tcp_session++;
}
- PRINT_D(TCP_ENH, "TCP Session %d to Ack %d\n", tcp_session, seq);
return 0;
}
@@ -310,8 +304,6 @@ static int wilc_wlan_txq_filter_dup_tcp_ack(struct
net_device *dev)
if (pending_acks_info[i].ack_num <
ack_session_info[pending_acks_info[i].session_index].bigger_ack_num) {
struct txq_entry_t *tqe;
- PRINT_D(TCP_ENH, "DROP ACK: %u\n",
- pending_acks_info[i].ack_num);
tqe = pending_acks_info[i].txqe;
if (tqe) {
wilc_wlan_txq_remove(wilc, tqe);
@@ -379,7 +371,6 @@ static int wilc_wlan_txq_add_cfg_pkt(struct wilc_vif *vif,
u8 *buffer,
tqe->tx_complete_func = NULL;
tqe->priv = NULL;
tqe->tcp_pending_ack_idx = NOT_TCP_ACK;
- netdev_dbg(vif->ndev, "Adding the config packet at the Queue tail\n");
if (wilc_wlan_txq_add_to_head(vif, tqe))
return 0;
@@ -408,7 +399,6 @@ int wilc_wlan_txq_add_net_pkt(struct net_device *dev, void
*priv, u8 *buffer,
tqe->tx_complete_func = func;
tqe->priv = priv;
- PRINT_D(TX_DBG, "Adding mgmt packet at the Queue tail\n");
tqe->tcp_pending_ack_idx = NOT_TCP_ACK;
if (is_tcp_ack_filter_enabled())
tcp_process(dev, tqe);
@@ -438,7 +428,6 @@ int wilc_wlan_txq_add_mgmt_pkt(struct net_device *dev, void
*priv, u8 *buffer,
tqe->tx_complete_func = func;
tqe->priv = priv;
tqe->tcp_pending_ack_idx = NOT_TCP_ACK;
- PRINT_D(TX_DBG, "Adding Network packet at the Queue tail\n");
wilc_wlan_txq_add_to_tail(dev, tqe);
return 1;
}
@@ -478,18 +467,15 @@ static int wilc_wlan_rxq_add(struct wilc *wilc, struct
rxq_entry_t *rqe)
mutex_lock(&wilc->rxq_cs);
if (!wilc->rxq_head) {
- PRINT_D(RX_DBG, "Add to Queue head\n");
rqe->next = NULL;
wilc->rxq_head = rqe;
wilc->rxq_tail = rqe;
} else {
- PRINT_D(RX_DBG, "Add to Queue tail\n");
wilc->rxq_tail->next = rqe;
rqe->next = NULL;
wilc->rxq_tail = rqe;
}
wilc->rxq_entries += 1;
- PRINT_D(RX_DBG, "Number of queue entries: %d\n", wilc->rxq_entries);
mutex_unlock(&wilc->rxq_cs);
return wilc->rxq_entries;
}
@@ -497,7 +483,6 @@ static int wilc_wlan_rxq_add(struct wilc *wilc, struct
rxq_entry_t *rqe)
static struct rxq_entry_t *wilc_wlan_rxq_remove(struct wilc *wilc)
{
- PRINT_D(RX_DBG, "Getting rxQ element\n");
if (wilc->rxq_head) {
struct rxq_entry_t *rqe;
@@ -505,11 +490,9 @@ static struct rxq_entry_t *wilc_wlan_rxq_remove(struct
wilc *wilc)
rqe = wilc->rxq_head;
wilc->rxq_head = wilc->rxq_head->next;
wilc->rxq_entries -= 1;
- PRINT_D(RX_DBG, "RXQ entries decreased\n");
mutex_unlock(&wilc->rxq_cs);
return rqe;
}
- PRINT_D(RX_DBG, "Nothing to get from Q\n");
return NULL;
}
@@ -643,7 +626,6 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32
*txq_count)
wilc_lock_timeout(wilc, &wilc->txq_add_to_head_cs,
CFG_PKTS_TIMEOUT);
wilc_wlan_txq_filter_dup_tcp_ack(dev);
- PRINT_D(TX_DBG, "Getting the head of t
Re: [PATCH] Staging:speakup:add space around '|'
On Sat, Jan 16, 2016 at 06:43:09PM +0530, Bhumika Goyal wrote: > Fix checkpatch.pl check:CHECK: spaces preferred around that '|'. > Add spaces around operands to fix these warnings. > > Signed-off-by: Bhumika Goyal > --- > drivers/staging/speakup/speakup_decext.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) This does not apply to my tree :( ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: wilc1000: remove warnings missing a blank line after declarations
From: Chris Park This patch remove warnings reported by checkpatch.pl for missing a blank line after declarations Signed-off-by: Chris Park Signed-off-by: Leo Kim --- drivers/staging/wilc1000/wilc_wlan.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c index 63b7492..8024cc2 100644 --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -1143,6 +1143,7 @@ int wilc_wlan_stop(struct wilc *wilc) u32 reg = 0; int ret; u8 timeout = 10; + acquire_bus(wilc, ACQUIRE_AND_WAKEUP); ret = wilc->hif_func->hif_read_reg(wilc, WILC_GLB_RESET_0, ®); -- 1.9.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/6] staging: wilc1000: Optimize code of wilc_get_chipid function
From: Chris Park
This patch optimize code of wilc_get_chipid function.
u8 type changed to boolean type and removed unnecessary if statement.
Signed-off-by: Chris Park
Signed-off-by: Leo Kim
---
drivers/staging/wilc1000/linux_wlan.c | 4 ++--
drivers/staging/wilc1000/wilc_wlan.c| 19 +++
drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
3 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/wilc1000/linux_wlan.c
b/drivers/staging/wilc1000/linux_wlan.c
index 22a2f98..9e5dea4 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -388,7 +388,7 @@ int wilc_wlan_get_firmware(struct net_device *dev)
vif = netdev_priv(dev);
wilc = vif->wilc;
- chip_id = wilc_get_chipid(wilc, 0);
+ chip_id = wilc_get_chipid(wilc, false);
if (chip_id < 0x1003a0)
firmware = FIRMWARE_1002;
@@ -475,7 +475,7 @@ static int linux_wlan_init_test_config(struct net_device
*dev,
wilc_get_mac_address(vif, mac_add);
netdev_dbg(dev, "MAC address is : %pM\n", mac_add);
- wilc_get_chipid(wilc, 0);
+ wilc_get_chipid(wilc, false);
*(int *)c_val = 1;
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index 8024cc2..1efd61a 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -1441,36 +1441,31 @@ static u32 init_chip(struct net_device *dev)
return ret;
}
-u32 wilc_get_chipid(struct wilc *wilc, u8 update)
+u32 wilc_get_chipid(struct wilc *wilc, bool update)
{
static u32 chipid;
u32 tempchipid = 0;
- u32 rfrevid;
+ u32 rfrevid = 0;
- if (chipid == 0 || update != 0) {
+ if (chipid == 0 || update) {
wilc->hif_func->hif_read_reg(wilc, 0x1000, &tempchipid);
wilc->hif_func->hif_read_reg(wilc, 0x13f4, &rfrevid);
if (!ISWILC1000(tempchipid)) {
chipid = 0;
- goto _fail_;
+ return chipid;
}
if (tempchipid == 0x1002a0) {
- if (rfrevid == 0x1) {
- } else {
+ if (rfrevid != 0x1)
tempchipid = 0x1002a1;
- }
} else if (tempchipid == 0x1002b0) {
- if (rfrevid == 3) {
- } else if (rfrevid == 4) {
+ if (rfrevid == 0x4)
tempchipid = 0x1002b1;
- } else {
+ else if (rfrevid != 0x3)
tempchipid = 0x1002b2;
- }
}
chipid = tempchipid;
}
-_fail_:
return chipid;
}
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h
b/drivers/staging/wilc1000/wilc_wlan_if.h
index 294552d..269c56e 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -921,6 +921,6 @@ struct wilc;
int wilc_wlan_init(struct net_device *dev);
void wilc_bus_set_max_speed(void);
void wilc_bus_set_default_speed(void);
-u32 wilc_get_chipid(struct wilc *wilc, u8 update);
+u32 wilc_get_chipid(struct wilc *wilc, bool update);
#endif
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/6] staging: wilc1000: remove useless function
From: Chris Park
This patch remove useless function remove_TCP_related
in wilc_wlan.c file
Signed-off-by: Chris Park
Signed-off-by: Leo Kim
---
drivers/staging/wilc1000/wilc_wlan.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index 30e3c21..7b3a260 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -206,15 +206,6 @@ static inline int add_tcp_pending_ack(u32 ack, u32
session_index,
}
return 0;
}
-static inline int remove_TCP_related(struct wilc *wilc)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&wilc->txq_spinlock, flags);
-
- spin_unlock_irqrestore(&wilc->txq_spinlock, flags);
- return 0;
-}
static inline int tcp_process(struct net_device *dev, struct txq_entry_t *tqe)
{
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6] staging: wilc1000: remove unnecessary braces
From: Chris Park
This patch remove warnings reported by checkpatch.pl
for unnecessary braces
Signed-off-by: Chris Park
Signed-off-by: Leo Kim
---
drivers/staging/wilc1000/wilc_wlan.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c
b/drivers/staging/wilc1000/wilc_wlan.c
index 7b3a260..63b7492 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -984,15 +984,15 @@ void wilc_handle_isr(struct wilc *wilc)
if (int_status & PLL_INT_EXT)
wilc_pllupdate_isr_ext(wilc, int_status);
- if (int_status & DATA_INT_EXT) {
+ if (int_status & DATA_INT_EXT)
wilc_wlan_handle_isr_ext(wilc, int_status);
- }
+
if (int_status & SLEEP_INT_EXT)
wilc_sleeptimer_isr_ext(wilc, int_status);
- if (!(int_status & (ALL_INT_EXT))) {
+ if (!(int_status & (ALL_INT_EXT)))
wilc_unknown_isr_ext(wilc);
- }
+
release_bus(wilc, RELEASE_ALLOW_SLEEP);
}
EXPORT_SYMBOL_GPL(wilc_handle_isr);
--
1.9.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
