Re: [PATCH] staging: rtsx: Add support for RTS5260

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote:
> On Fri, 13 Oct 2017, Greg KH wrote:
> 
> > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_feng@realsil.com.cn wrote:
> > > From: rui_feng <rui_feng@realsil.com.cn>
> > > 
> > > Add support for new chip rts5260.
> > > In order to support rts5260，the definitions of some internal
> > > registers and workflow have to be modified and are different from its
> > > predecessors and OCP function is added for RTS5260.
> > > So we need this patch to ensure RTS5260 can work.
> > > 
> > > Signed-off-by: Rui Feng <rui_feng@realsil.com.cn>
> > 
> > Your from and signed-off-by name does not match :(
> > 
> > > ---
> > >  drivers/mfd/Makefile              |   4 +
> > >  drivers/mfd/rtsx_pcr.c            | 127 ++++++-
> > >  drivers/mfd/rtsx_pcr.h            |  12 +
> > >  drivers/staging/Kconfig           |   2 +
> > >  drivers/staging/rts5260/Kconfig   |   6 +
> > >  drivers/staging/rts5260/rts5260.c | 748 ++++++++++++++++++++++++++++++++++++++
> > >  drivers/staging/rts5260/rts5260.h |  45 +++
> > >  include/linux/mfd/rtsx_pci.h      | 234 +++++++++++-
> > 
> > I do not see a reason why this is a staging driver.  Where is the TODO
> > file listing what needs to be done to get it out of staging?  Why can it
> > not just go into the "real" part of the kernel?
> 
> It's not a staging driver.  Rui's focus appears to be to have this
> driver accepted into Mainline by hook or by crock.  He's tried MFD,
> Misc and now Staging!

Yeah, I've watched it too :)

> Background:
> 
> There are a number of drivers in this family which currently reside in
> MFD.  These were accepted before my time.  After a recent review I've
> made the decision that these aren't MFD drivers at all.
> 
> MFD drivers are ones which aid in registering and setting up shared
> resources for sub-devices which reside on the same piece of silicon.
> This driver does basically none of that.  Instead it *is* the (what we
> describe above as) sub-device.  It does everything.

I agree with your assessment.

> In the absence of a subsystem which covers this type of device, I
> suggested Misk as a good location to place these drivers.

What type of device is this thing?  I can't seem to figure that out.  If
we can determine that, then we can find the proper place for it in the
kernel.

Rui, what does this hardware do?  What is the interface between the
hardware and userspace that this driver is creating?

thanks,

greg k-h