lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YS/pzJCV8MiwOPRB@equinox>
Date:   Wed, 1 Sep 2021 21:59:56 +0100
From:   Phillip Potter <phil@...lpotter.co.uk>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     gregkh@...uxfoundation.org, arnd@...db.de,
        Larry.Finger@...inger.net, akpm@...ux-foundation.org,
        sfr@...b.auug.org.au, linux-kernel@...r.kernel.org,
        linux-staging@...ts.linux.dev
Subject: Re: [GIT PULL] Staging / IIO driver changes for 5.15-rc1

On Wed, Sep 01, 2021 at 09:49:47AM -0700, Linus Torvalds wrote:
> On Wed, Sep 1, 2021 at 7:17 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > Lots of churn in some staging drivers, we dropped the "old" rtl8188eu
> > driver and replaced it with a newer version of the driver that had been
> > maintained out-of-tree by Larry with the end goal of actually being able
> > to get this driver out of staging eventually.  Despite that driver being
> > "newer" the line count of this pull request is going up.
> 
> Ugh.
> 
> So this had a conflict with the networking tree, and commit
> 89939e890605 ("staging: rtlwifi: use siocdevprivate") in particular.
> 
> Ok, so that conflict looked annoying but harmless - git saw the new
> driver as a rename of the old one, and tried to actually apply the
> changes from that commit to the new one.
> 
> And git actually did a reasonable job, everything considered. There
> were enough similarities that it wasn't entirely crazy, and enough
> differences that it caused conflicts.
> 
> HOWEVER.
> 
> Actually then looking at the root causes of the conflicts, as part of
> just trying to finish what git had started, I notice that a lot of the
> code in the new driver was just completely dead.
> 
> As of commit ae7471cae00a ("staging: r8188eu: remove rtw_ioctl
> function") the only caller of rtw_android_priv_cmd() is entirely gone.
> 
> But rtw_android_priv_cmd() was kept around, and was in fact the only
> reason that the files
> 
>     drivers/staging/r8188eu/include/rtw_android.h
>     drivers/staging/r8188eu/os_dep/rtw_android.c
> 
> existed at all.
> 
> End result: instead of trying to fix up the conflict in dead code, I
> just ripped out the code completely.
> 
> So my merge actually looks simple and clean: when you look at the
> conflict diff of my merge, all you see is that I removed
> 'os_dep/rtw_android.o' from drivers/staging/r8188eu/Makefile.
> 
> What you don't actually see as a conflict, is that I removed those
> files entirely. That removal doesn't show up as "conflicts", because
> that filename didn't exist in my HEAD commit before the merge at all
> (because my tree had that old "rtl8188eu" driver).
> 
> So this email is just a long explanation for what I did, to make
> people aware that maybe I screwed up. It builds for me, and honestly,
> it makes sense to me in ways that your git tree did not, but I can't
> test any of it.
> 
> Added Arnd (for the siocdevprivate conversion) and Phillip/Larry (for
> the r8188eu driver side) - can you please double-check what I did.
> 
>                    Linus

Dear Linus,

Thank you for merging the code and resolving the merge conflict firstly,
much appreciated.

You have not screwed up - the driver still works, I've just built it
from your tree and tested this kernel with my USB-N10 Nano, and it works as
expected. Indeed, other than the removal of the unused Android code, the
driver is identical to the one in staging according to my checks with diff
etc.

I left this code in when I wrote ae7471cae00a ("staging: r8188eu: remove
rtw_ioctl function") with the intention of modifying and reconnecting,
once the changes to struct net_device_ops made their way into the
staging tree. Removal of it is not an issue though, it can always be
reintroduced as and when myself or someone else gets a chance to do it,
assuming this is worthwhile - others may have an opinion on that also
:-)

Regards,
Phil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ