On Fri, 13 Oct 2017, Greg KH wrote: > 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@xxxxxxxxxxxxxx wrote: > > > > From: rui_feng <rui_feng@xxxxxxxxxxxxxx> > > > > > > > > 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@xxxxxxxxxxxxxx> > > > > > > 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. Sorry, that should have been "Misc" > 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. It's a card (MMC, (u)SD, etc) reader. > Rui, what does this hardware do? What is the interface between the > hardware and userspace that this driver is creating? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
