linux-kernel - Re: [PATCH v4] staging: nrf24: add new driver for 2.4GHz radio transceiver

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

Message-ID: <20190223080017.GC2640@kroah.com>
Date:   Sat, 23 Feb 2019 09:00:17 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Marcin Ciupak <marcin.s.ciupak@...il.com>
Cc:     Joe Perches <joe@...ches.com>, devel@...verdev.osuosl.org,
        linux-kernel@...r.kernel.org,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH v4] staging: nrf24: add new driver for 2.4GHz radio
 transceiver

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@...il.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