Re: feedback on mainlining wilc1000 staging driver

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

On Fri, 17 Aug 2018 11:36:02 +0300
Kalle Valo <kvalo@codeaurora.org> wrote:

> Arend van Spriel <arend.vanspriel@broadcom.com> writes:
> 
> > On 8/17/2018 9:49 AM, Kalle Valo wrote:  
> >> Ajay Singh <ajay.kathat@microchip.com> writes:
> >>  
> >>> On Thu, 16 Aug 2018 13:53:50 +0300
> >>> Kalle Valo <kvalo@codeaurora.org> wrote:
> >>>  
> >>>> Kalle Valo <kvalo@codeaurora.org> writes:
> >>>>  
> >>>>>  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.  
> 
> Another option is to split it so that there's one patch per file,
> should be even pretty easy to automate that. It's just so much easier
> to comment on a patch submitted by email compared to the reviewer
> manually copying code and then commenting it, yuck.
> 

Sure. I will prepare a patch per file send for review as its easy to
review.

As Greg suggested, I will wait for the merge window to close and
after completing pending patches to staging, I will start the review.

For my understanding, the patches for review will be based on
wireless-testing branch. And the fixes will be submitted to staging tree
in parallel. right?

Regards,
Ajay