On Tue, Dec 1, 2009 at 4:58 PM, Mark Brown <broo...@sirena.org.uk> wrote: > On Tue, Dec 01, 2009 at 10:24:30AM +0530, pavan savoy wrote: > >> When I meant android specific, I meant that it is only android that is >> making use of an rfkill entry to toggle the BT Chip enable GPIO line. >> Example: In other linux-bluetooth stacks (including blueZ on a busybox >> sort of FS), this can be done via an sysfs entry or BT driver itself >> or have it high @ boot in one of the board-*.c files from arch/*/... >> directory. > > I'm not sure which system you're looking at here but there's embedded > boards in mainline which use rfkill for Bluetooth (eg, tosa) - the fact > that some things have managed to get merged without using the standard > interfaces shouldn't prevent new users using the standard interfaces. > Ok, then I still have to look around for more uses of rfkill...
>> Also, Nick -- Should I be migrating to 2.6.32 ? to upstream this patch to >> lkml ? >> there are some HUGE changes to 2.6.32 rfkill sub-system !!! > > Yes, upstream will only be interested in something for a current kernel. > IIRC a lot of the restructuring you're looking at was actually largely > about making things nicer for non-WiFi rfkill users. Not sure on this one, the sysfs entry sort of a mechanism worked like a charm, no handling of any uevents, echo and cat were all that's needed. Now someone should be looking over these rfkill devices [udevd] - not sure how... and also not sure how this is gonna work for Android ?? Nick, any ideas ?? [are we going back to /sys/board-tryout/ ?? > > -- > unsubscribe: android-kernel+unsubscr...@googlegroups.com > website: http://groups.google.com/group/android-kernel -- --Pavan Savoy -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
