> Chip vendor provides a MPL (motion processing library) to control the > micro-processor on chip via ioctl. (MPL includes some patent motions, > dynamic firmware and algorithms for gyroscope, accelerometer and > e-compass.) On the other hand, sensor framework in meego will > communicate with device via sysfs to get raw data and control power > mode. So, in this patch, the driver keeps these two interfaces. Could > meego kernel accept this?
At the point you've got something which claims to have GPL components that are not usable without non-GPL components the upstream (Linus) kernel policy is not to accept those interfaces. If they are general purpose interfaces that can be used by other apps then it's usually OK or if the kernel driver produces generally useful output. There are licensing reasons for this policy in the upstream kernel - in particular whether the two parts are really two independent works. That's something for legally qualified people to debate so I can't further that element of any needed discussion. > > - Register the I²C bus as a kernel I²C bus when not being used by > > the device (would allow sharing of standard I²C drivers for modules > > like compasses off it > > In this driver, the part of accelerometer and compass collocates with > core of gyroscope driver, because this is an auxiliary component for > gyroscope, which needs this component to fix the drift of gyroscope. > This architecture is designed for MPL. (Does this answer your > question?) I don't think so. You have duplicate drivers for various devices and ioctl interfaces for talking to the I²C bus on the device that are only duplicate because the device doesn't expose that bus to the existing drivers. I'd have thought doing that was in your interest and the vendors as it would allow the bus to be used for other supported devices as well ? > > - Style wise remove various wrappers, fix for Linux style and > > comment style (probably best done as a last item) > > - Possibly use request_firmware for the uploads to the device ? > > The firmware update is already implemented in MPL, so the function > name might not be changed. So is the real question "Can this code go into Meego unchanged, and with the possibility of changes being vetoed because there are fixed dependencies on a binary library" ? I guess the other question would be "which features do you need to be in the kernel" - which bits do you actually plan to use. Alan _______________________________________________ MeeGo-kernel mailing list [email protected] http://lists.meego.com/listinfo/meego-kernel
