Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Sat, 23 Feb 2019 09:00:17 +0100
From:   Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To:     Marcin Ciupak <marcin.s.ciupak@gmail.com>
Cc:     Joe Perches <joe@perches.com>, devel@driverdev.osuosl.org,
        linux-kernel@vger.kernel.org,
        Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [PATCH v4] staging: nrf24: add new driver for 2.4GHz radio
 transceiver
Message-ID: <20190223080017.GC2640@kroah.com>
References: <20190213194035.n2ldlt7xque5qaps@metis.ciupak.eu>
 <20190219102010.GA18634@kroah.com>
 <20190222202055.udjbsm5qkxzkqcdh@metis.ciupak.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190222202055.udjbsm5qkxzkqcdh@metis.ciupak.eu>
User-Agent: Mutt/1.11.3 (2019-02-01)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Feb 22, 2019 at 09:20:56PM +0100, Marcin Ciupak wrote:
> On Tue, Feb 19, 2019 at 11:20:10AM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 13, 2019 at 08:40:35PM +0100, Marcin Ciupak wrote:
> > > This patch adds driver for Nordic Semiconductor nRF24L01+ radio
> > > transceiver.
> > > 
> > > Signed-off-by: Marcin Ciupak <marcin.s.ciupak@gmail.com>
> > > ---
> > > Changes in v2:
> > >   - add terminating newlines to all logging formats
> > > Changes in v3:
> > >   - patch subject
> > >   - comments cleanup
> > >   - goto labels cleanup
> > >   - scnprintf bugfix
> > >   - ida_simple_remove bugfix
> > > Changes in v4:
> > >   - fix smatch warnings
> > 
> > What is preventing this from being merged today with the normal
> > subsystem for this type of drivers?  Why does this have to go into
> > staging?
> > 
> > thanks,
> > 
> > greg k-h
> 
> As per TODO file:
> +Todo:
> +- opening and closing pipes via sysfs

That's not what sysfs is for, so that can't be a TODO item :)

> +- improve switching in between RX and TX
> +- improve handling of MAX_RT interrupt

That's just logic cleanup, no reason to have it in staging.

> +- find and fix bugs

Same here.

> +- code cleanup

What specifically do you mean by this?  And why can't you just spend a
day and do it now?

> 
> Additionally, I would like to add ioctl (or any similar) interface
> as configuration via sysfs is not very efficent in here.

sysfs is not for configuration, that is what configfs is for, please use
that instead.

> My beliefes are that this driver needs some time in staging, but I might
> be wrong and if you believe otherwise just let me know and I will try to
> push it ti regular sybsystem.

I think you need to use the standard apis that the kernel has for
drivers like this (v4l?) and work on getting the driver into the proper
subsystem first.  I don't see what the goal of getting it into staging
is going to do to help you out with that.

thanks,

greg k-h