On 8/17/2018 9:49 AM, Kalle Valo wrote:
Ajay Singh <ajay.kathat@xxxxxxxxxxxxx> writes:
On Thu, 16 Aug 2018 13:53:50 +0300
Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote:
Kalle Valo <kvalo@xxxxxxxxxxxxxx> writes:
Ajay Singh <ajay.kathat@xxxxxxxxxxxxx> writes:
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
From wireless point of view: if I see wext mentioned anywhere in the
driver I stop right there. cfg80211 is a hard requirement for us
nowadays.
Clarification: Depending on the hardware design either cfg80211 or
mac80211 is a hard requirement. I haven't checked wilc1000 at all so I
don't know what design it has but if it's a "softmac" design then it
has to use mac80211, we do not want to support multiple 802.11 UMAC
stacks.
The TODO item to make use of wext-core is obsolete. Previously wilc1000
driver also had few wext ioctl use but now it’s completely removed and
cfg80211 operation callbacks are used.
wilc1000 driver make use of cfg80211 and isn’t a "softmac".
Good.
We need help to review and identify if there are any pending items
for wilc1000 driver, so we can address those issues and make it ready
to move to the wireless subsystem.
I think the best way to get that forward is to submit a patch (or
patchset) to linux-wireless, that's the easiest for reviewers.
For brcm80211 drivers we used a single patch introducing it under the
wireless drivers folder. Because it was quite a sizable patch we parked
it on the wireless wiki page. Had a few iterations doing it like that.
Regards,
Arend
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
