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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 16 Apr 2020 13:57:11 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     "Ramuthevar, Vadivel MuruganX" 
        <vadivel.muruganx.ramuthevar@...ux.intel.com>
Cc:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        anders.roxell@...aro.org, andriy.shevchenko@...el.com,
        arnd@...db.de, brendanhiggins@...gle.com, cheol.yong.kim@...el.com,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mtd@...ts.infradead.org, masonccyang@...c.com.tw,
        miquel.raynal@...tlin.com, piotrs@...ence.com,
        qi-ming.wu@...el.com, richard@....at, robh+dt@...nel.org,
        tglx@...utronix.de, vigneshr@...com
Subject: Re: [PATCH v1 2/2] mtd: rawnand: Add NAND controller support on
 Intel LGM SoC

On Thu, 16 Apr 2020 19:38:03 +0800
"Ramuthevar, Vadivel MuruganX"
<vadivel.muruganx.ramuthevar@...ux.intel.com> wrote:

> On 16/4/2020 7:17 pm, Boris Brezillon wrote:
> > On Thu, 16 Apr 2020 18:40:53 +0800
> > "Ramuthevar, Vadivel MuruganX"
> > <vadivel.muruganx.ramuthevar@...ux.intel.com> wrote:
> >  
> >>>>> we'll be happy to have one more of the existing driver converted to  
> >>>>> ->exec_op() ;-).  
> >>>> I have completely adapted to ->exec_op() hook up to replace the legacy
> >>>> call-back.  
> >>> I suspect porting what you've done to the xway driver shouldn't be too
> >>> complicated.  
> >> Not ported from xway_nand.c driver , we have developed from the scratch
> >> to make it work on
> >> Intel LGM SoC , it's new x86 ATOM based SoC, IP itself completely
> >> different and most of the registers won't match.
> >> if we port then it would be ugly and also what are the problem may occur
> >> we do not know.  
> > Sorry but IMO they look similar enough to try to merge them.  
> 
> Thanks! Boris, need suggestion from you since you are maintainer and 
> also expertise on mtd-subsystem.

I *was* the maintainer :).

> 
> There are different features involved and lines of code is more, if we 
> add new driver patches over xway-nand driver

How about retro-fitting the xway logic into your driver then? I mean,
adding a 100 lines of code to your driver to get rid of the 500+ lines
we have in xway_nand.c is still a win.

> 
> is completely looks ugly and it may disturb the existing functionality 
> as well since we don't have platform to validate:'(.

How ugly? Can you show us? Maybe we can come with a solution to make it
less ugly.

As for the testing part, there are 4 scenarios:

1/ Your changes work perfectly fine on older platforms. Yay \o/!
2/ You break the xway driver and existing users notice it before this
   series gets merged. Now you found someone to validate your changes.
3/ You break the xway driver and none of the existing users notice it
   before the driver is merged, but they notice it afterwards. Too bad
   this happened after we've merged the driver, but now you've found
   someone to help you fix the problem :P.
4/ You break things for old platforms but no one ever complains about
   it, either because there's no users left or because they never
   update their kernels. In any case, that's no longer your problem.
   Someone will remove those old platforms one day and get rid of the
   unneeded code in the NAND driver.

What's more likely to happen is #3 or #4, and I think the NAND
maintainer would be fine with both.

Note that the NAND subsystem is full of unmaintained legacy drivers, so
every time we see someone who could help us get rid or update one of
them we have to take this opportunity.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ