feedback on mainlining wilc1000 staging driver

[Ajay Singh <ajay.kathat@microchip.com>]

Hi Greg,

We all are working on submitting and reviewing patches for wilc1000 in
staging driver for quite some time. 

We would like to have feedback on the next steps to bring wilc1000
driver closer to move into the wireless subsystem tree. 

In summary, the following major things from TODO have been addressed in
staging:
-remove the defined feature as kernel versions
-remove OS wrapper functions
-remove custom debug and tracing functions
-rework comments and function headers(also coding style)
-remove build warnings
-replace all semaphores with mutexes or completions
-make spi and sdio components coexist in one build
-turn compile-time platform configuration (BEAGLE_BOARD, PANDA_BOARD,
PLAT_WMS8304, PLAT_RKXXXX, CUSTOMER_PLATFORM, ...) into run-time
options that are read from DT
-replace SIOCDEVPRIVATE commands with generic API functions
-use wext-core handling instead of private SIOCSIWPRIV implementation
-Move handling for each individual members of 'union message_body' out
into a separate 'struct work_struct' and completely remove the
multiplexer that is currently part of host_if_work(), allowing movement
of the implementation of each message handler into the callsite of the
function that currently queues the 'host_if_msg'.
-convert all uses of the old GPIO API from <linux/gpio.h> to the GPIO
descriptor API in <linux/gpio/consumer.h> and look up GPIO lines from
device tree, ACPI or board files, board files should use
<linux/gpio/machine.h>

I have few patches to submit based on last week comments. I
will send these patches as soon as the merge window is closed.

1. Delete wilc_debugfs.c file, as not used.
2. Remove use of remaining global variables.
3. Remove udelay realted checkpatch warning.
4. Use void return for function whose return value is not used.


Currently, there are 2 known items pending in our TODO. 
-support soft-ap and p2p mode
-support resume/suspend function
 
For the above 2 remaining TODO items, we need to add extra code but as
suggested in [1], we have not taken up this activity yet.
 
We would like to know your opinion whether we should start working on
these features in staging-next tree or take it up after having moved
the code to wireless sub-system.

Do you think it’s better to initiate review in parallel with
wireless subsystem maintainer to identify any pending TODO items. 

Please guide us on how to proceed further.

[1] . https://patchwork.kernel.org/patch/9809145
 

Regards,
Ajay