Why not the chip manufacturers decide - how best to turn on their chip and move the system/bluetooth/bluedroid project under hardware/libhardware 'ala wifi, so that manufacturer is free to have his own functions.
regards, Pavan On Thu, Mar 11, 2010 at 7:12 PM, Nick Pelly <npe...@google.com> wrote: > What do you suggest as an alternative? > > On Thu, Mar 11, 2010 at 2:15 PM, pavan savoy <pavan.sa...@gmail.com> > wrote: > > Android when it wants to turn BT on, write's 1 onto the rfkill entry > (which > > has type bluetooth), > > and up until now this is the reason we had wl127x_rfkill.c on OMAP or > > board-*-rfkill.c on MSM. > > > > However a hci_register_dev from 2.6.32 also creates and rfkill entry by > the > > same type - bluetooth. > > > > Now both or any of these rfkill entries may be used, unfortunately we > have > > to manually change the permissions of either of them. > > This can be put in the init.rc if BT driver exists in kernel by default, > but > > by this we cannot have it as a module and hotplug it into the kernel as > and > > when required. > > > > So my question is - why is this turning on of rfkill entry so very > > desperately required in android. > > As Dmitry Torokhov quoted "Well, this just indicates that this portion of > > Android code is sploppy" > > -- > > --Pavan Savoy > > > > -- > > unsubscribe: > > android-kernel+unsubscr...@googlegroups.com<android-kernel%2bunsubscr...@googlegroups.com> > > website: http://groups.google.com/group/android-kernel > > -- > unsubscribe: > android-kernel+unsubscr...@googlegroups.com<android-kernel%2bunsubscr...@googlegroups.com> > website: http://groups.google.com/group/android-kernel -- --Pavan Savoy -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
