Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, Jun 24, 2020 at 12:49:24PM +0300, Kalle Valo wrote: >> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: >> >> > On Wed, Jun 24, 2020 at 11:50:07AM +0300, Kalle Valo wrote: >> >> <Ajay.Kathat@xxxxxxxxxxxxx> writes: >> >> >> >> > From: Ajay Singh <ajay.kathat@xxxxxxxxxxxxx> >> >> > >> >> > This patch series is to review and move wilc1000 driver out of staging. >> >> > Most of the review comments received in [1] & [2] are addressed in the >> >> > latest code. >> >> > Please review and provide your inputs. >> >> > >> >> > [1]. https://lore.kernel.org/linux-wireless/1537957525-11467-1-git-send-email-ajay.kathat@xxxxxxxxxxxxx/ >> >> > [2]. https://lore.kernel.org/linux-wireless/1562896697-8002-1-git-send-email-ajay.kathat@xxxxxxxxxxxxx/ >> >> > >> >> > Changes since v6: >> >> > - added Reviewed-by tag received for DT binding document patch earlier. >> >> > * https://lore.kernel.org/linux-wireless/20200405013235.GA24105@bogus >> >> > - merged latest driver and included --base commit as suggested. >> >> >> >> Greg, in preparation for moving the driver to drivers/net/wireless can I >> >> ask you to not to take wilc1000 patches for the time being? I think that >> >> way it would be easier to move the driver between trees if there are no >> >> changes after v5.8-rc1. Or is there a better way handle the move? >> > >> > The best way is for there to be a series of patches that just adds the >> > driver to the "real" part of the tree, and when that is merged, let me >> > know and I will just delete the driver version in the staging tree. >> > >> > Does that work for you? >> >> It would be fine for me but won't that approach break the build (eg. >> allyesconfig) due to two duplicate versions of the same driver in >> wireless-drivers-next? > > For maybe one day, yes, but that's all. > >> What I was thinking that Ajay would create a patch moving the driver >> from drivers/staging/wilc1000 to >> drivers/net/wireless/microchip/wilc1000. Using 'git mv' and 'git >> format-patch --find-renames' the patch should be really small, mostly >> just renames and small changes to Kconfig, Makefile and MAINTAINERS >> files. But this of course would require that there are no wilc1000 >> patches in your tree until you get the driver move commit during the >> next merge window, otherwise we would see conflicts between staging-next >> and wireless-drivers-next. >> >> But I don't have any strong opinions, whatever is easiest for everyone :) > > It's kind of hard to review patches that do moves, but if you all want > to do that, that's fine with me. Actually we have been reviewing the driver with full diffs, one file per patch style[1], so I think everyone are happy. At least I have not heard any complaints. And Ajay already submitted that the simple rename patch proposed, thanks Ajay! https://patchwork.kernel.org/patch/11625025/ And indeed the patch is simple as it can get. So Greg, if it's ok for you I would like to apply that simple patch to wireless-drivers-next. > Note, I can't guarantee that I'll not take any wilc1000 patches, I'll > probably forget, but git mv will handle all of that just fine. Good point. To be on the safe side one option is that if I create a topic branch for this simple patch and use v5.8-rc1 as the baseline. Then I would pull the topic branch to wireless-drivers-next and you could pull it to staging-next. That way you would not have wilc1000 in your tree anymore and no accidental submission or commits either :) What do you think? [1 ] https://patchwork.kernel.org/project/linux-wireless/list/?series=307223&state=*&order=date -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
