linux-kernel - Re: [PATCH v2] staging: fsl-mc: move bus driver out of staging

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20171128125903.GA13019@kroah.com>
Date:   Tue, 28 Nov 2017 13:59:03 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Laurentiu Tudor <laurentiu.tudor@....com>
Cc:     "devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
        "stuyoder@...il.com" <stuyoder@...il.com>,
        Stuart Yoder <stuart.yoder@....com>,
        Roy Pledge <roy.pledge@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "agraf@...e.de" <agraf@...e.de>,
        Catalin Horghidan <catalin.horghidan@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Leo Li <leoyang.li@....com>,
        Bharat Bhushan <bharat.bhushan@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2] staging: fsl-mc: move bus driver out of staging

On Mon, Nov 27, 2017 at 03:32:28PM +0000, Laurentiu Tudor wrote:
> 
> 
> On 11/03/2017 05:17 PM, Greg KH wrote:
> > On Thu, Aug 31, 2017 at 06:04:30PM +0200, Greg KH wrote:
> >> On Mon, Aug 28, 2017 at 01:54:05PM +0300, laurentiu.tudor@....com wrote:
> >>> From: Stuart Yoder <stuart.yoder@....com>
> >>>
> >>> Move the source files out of staging into their final locations:
> >>>    -include files in drivers/staging/fsl-mc/include go to include/linux/fsl
> >>>    -irq-gic-v3-its-fsl-mc-msi.c goes to drivers/irqchip
> >>>    -source in drivers/staging/fsl-mc/bus goes to drivers/bus/fsl-mc
> >>>    -README.txt, providing and overview of DPAA goes to
> >>>     Documentation/dpaa2/overview.txt
> >>>
> >>> Update or delete other remaining staging files-- Makefile, Kconfig, TODO.
> >>> Update dpaa2_eth and dpio staging drivers.
> >>>
> >>> Signed-off-by: Stuart Yoder <stuyoder@...il.com>
> >>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@....com>
> >>> [Laurentiu: rebased, add dpaa2_eth and dpio #include updates]
> >>> Cc: Thomas Gleixner <tglx@...utronix.de>
> >>> Cc: Jason Cooper <jason@...edaemon.net>
> >>> Cc: Marc Zyngier <marc.zyngier@....com>
> >>
> >> This is going to have to wait until I get a chunk of time to do the
> >> review.  Probably after 4.13-final is out.
> >
> > Ok, review comments as I go through the code:
> > 	mc-sys.c             323 EXPORT_SYMBOL(mc_send_command);
> >
> > should be EXPORT_SYMBOL_GPL(fsl_mc_send_command); to match up with your
> > other exports and global namespace, right?
> >
> > You export a lot of dpcon_* symbols that no one uses, please do not do
> > that.  Verify that all of them are actually used right now, if not,
> > remove them.  If you think you are going to use them in the future,
> > wonderful, add them in then.
> >
> > Same for your dpaa2_* exported symbols, most are not used from what I
> > can see.
> >
> > struct dpaa2_io {
> >          atomic_t refs;
> >
> > That's a kref, please use it instead of trying to roll your own.
> >
> > And even for this, your locking is not correct (i.e. you do not have
> > any), that needs to be fixed so that teardown works correctly.
> >
> > You have a lot of WARN_ON() calls, that's going to be ignored and should
> > all not be needed now that the code is debugged and working properly.
> > Please remove them, or turn them into dev_err() calls with a real if ()
> > check instead.
> >
> > You are checking "strings" for the type of device in a lot of places,
> > like this:
> > 	        if (strcmp(obj_desc->type, "dprc") == 0) {
> > why are you not just using the built-in driver model .type field and
> > comparing that to the different type structures?  It's much easier, and
> > you don't have to again, "roll your own".  See the USB or Greybus code
> > for examples of busses that have different "types" of devices on them at
> > the same time.
> >
> > Ok, that's enough for now, please work on this, and we can go from
> > there...
> >
> 
> What would the next steps be, now that the patches are in staging-next?
> Are there plans for a new round of review?

Send a patch that moves the files you think should be moved at this
point in time, as I'm not quite sure which ones exactly you feel are
ready to go.

thanks,

greg k-h