On Mon, Nov 30, 2009 at 10:22:56AM +0530, pavan savoy wrote: > On Fri, Nov 27, 2009 at 7:50 PM, Mark Brown <broo...@sirena.org.uk> wrote:
> > Yes, most kernel work is largely independant of Android and so will be > > just as useful in the mainline kernel. > Useful ? I couldn't see how. Well, if Android can use the functionality of the hardware it should be possible for other userspace stacks to make use of it. > >> The rfkill driver is merged, happily working on the android-kernel > >> tree (omap/ tree specifically), but it is only android that is worried > >> about anything like rfkill for bluetooth (not even linked to rfkill > >> input sub-system) !!! > > What makes you say this? > This is because Android's BT-On app (+ library) considers turning on > of the chip as writing "1" to an rfkill entry. This forces a developer > to write an rfkill driver for it. Which would probably not make sense rfkill isn't at all Android specific, it's a standard part of the kernel ABI and used by other applications too. What do you see as being Android specific in this usage? > if say its a USB bluetooth chip or chip doesn't have an chip enable > gpio line. If the driver isn't doing anything then obviously that's a separate issue but again I have to ask what makes you say that this is specific to Android. Other user space software that uses rfkill will be faced with the same issue. > [probably many other cases like this, ex: WLAN driver to be insmod-ed !!] I'm not sure what you mean by that example, though it sounds like a bodge to get round a buggy or incomplete wireless driver. If there are general cases where rfkill functionality is implemented in user space it would probably make sense to ensure that there is a standard interface that for userspace to hook in to. > So, I never considered submitting this driver to open-source... > http://android.git.kernel.org/?p=kernel/omap.git;a=blob;f=drivers/misc/wl127x-rfkill.c;h=aa8d4623c1be5001e9b8d24381b68ea868724f1c;hb=refs/heads/android-omap-2.6.29 I certainly don't see anything Android-specific there. It might be better to make more of the driver configurable from platform data so that -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
