| Message ID | 1249169809-11853-1-git-send-email-tomas.winkler@intel.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
Hi Tomas, > Althoug GPS is a technology w/o transmitting radio > and thus not a primary candidate for rfkill switch, > rfkill gives unified interface point for devices with > wireless technology. > > The input key is not supplied as it is too be deprecated. > > Cc: johannes@sipsolutions.net > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> we don't have a GPS subsystem, but even without it, I think this is a good thing to have. Acked-by: Marcel Holtmann <marcel@holtmann.org> Please also send a patch updating the rfkill userspace utility. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 2, 2009 at 3:04 AM, Marcel Holtmann<marcel@holtmann.org> wrote: > Hi Tomas, > >> Althoug GPS is a technology w/o transmitting radio >> and thus not a primary candidate for rfkill switch, >> rfkill gives unified interface point for devices with >> wireless technology. >> >> The input key is not supplied as it is too be deprecated. >> >> Cc: johannes@sipsolutions.net >> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> > > we don't have a GPS subsystem, but even without it, I think this is a > good thing to have. GPS devices are usually serial devices. > Acked-by: Marcel Holtmann <marcel@holtmann.org> > > Please also send a patch updating the rfkill userspace utility. On the way.... Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2009-08-02 at 08:49 +0300, Tomas Winkler wrote: > > we don't have a GPS subsystem, but even without it, I think this is a > > good thing to have. > > GPS devices are usually serial devices. Yeah, this is interesting -- do we want something like /dev/urfkill (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same applies for 3G) can be controlled with rfkill? johannes
On Sun, Aug 2, 2009 at 10:45 AM, Johannes Berg<johannes@sipsolutions.net> wrote: > On Sun, 2009-08-02 at 08:49 +0300, Tomas Winkler wrote: > >> > we don't have a GPS subsystem, but even without it, I think this is a >> > good thing to have. >> >> GPS devices are usually serial devices. > > Yeah, this is interesting -- do we want something like /dev/urfkill > (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same > applies for 3G) can be controlled with rfkill? Sorry don't know much about /dev/uinput what is difference between /dev/urfkill and /dev/rfkill, can you be, please more verbose Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tomas, > >> > we don't have a GPS subsystem, but even without it, I think this is a > >> > good thing to have. > >> > >> GPS devices are usually serial devices. > > > > Yeah, this is interesting -- do we want something like /dev/urfkill > > (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same > > applies for 3G) can be controlled with rfkill? > > Sorry don't know much about /dev/uinput what is difference between > /dev/urfkill and /dev/rfkill, can you be, please more verbose the uinput allows you to write a input driver in userspace. So with urfkill you could in theory write a RFKILL switch as a userspace program. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Johannes, > > > we don't have a GPS subsystem, but even without it, I think this is a > > > good thing to have. > > > > GPS devices are usually serial devices. > > Yeah, this is interesting -- do we want something like /dev/urfkill > (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same > applies for 3G) can be controlled with rfkill? on one hand I think urfkill might be needed, on the other hand I think we should not do it at all. Currently I would think it is better to force the RFKILL integration in the kernel so that we have proper subsystem integration, or platform RFKILL switches or in cases like GPS and WWAN/3G it will be driver integration. For 3G we already have the hso.ko driver which has a killswitch and we just need to fix the other ones. I am actually looking into it, if this is possible without an AT parser inside the kernel. So the GPS world is evolving right now and that everybody implements them as kernel-tty-passthrough pseudo driver and then a binary only daemon and then gpsd/gypsy on top of it will only survive for certain amount of time. The binary component will not get wide acceptance. And even if the binary only userspace component stays, we might still need a proper GPS subsystem since using TTY as pure transport is holding us back. Could be that AF_GPS would have been a way better choice. This will sort itself out over time. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 2, 2009 at 7:28 PM, Marcel Holtmann<marcel@holtmann.org> wrote: > Hi Johannes, > >> > > we don't have a GPS subsystem, but even without it, I think this is a >> > > good thing to have. >> > >> > GPS devices are usually serial devices. >> >> Yeah, this is interesting -- do we want something like /dev/urfkill >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same >> applies for 3G) can be controlled with rfkill? > > on one hand I think urfkill might be needed, on the other hand I think > we should not do it at all. Currently I would think it is better to > force the RFKILL integration in the kernel so that we have proper > subsystem integration, or platform RFKILL switches or in cases like GPS > and WWAN/3G it will be driver integration. For 3G we already have the > hso.ko driver which has a killswitch and we just need to fix the other > ones. I am actually looking into it, if this is possible without an AT > parser inside the kernel. > > So the GPS world is evolving right now and that everybody implements > them as kernel-tty-passthrough pseudo driver and then a binary only > daemon and then gpsd/gypsy on top of it will only survive for certain > amount of time. The binary component will not get wide acceptance. And > even if the binary only userspace component stays, we might still need a > proper GPS subsystem since using TTY as pure transport is holding us > back. Could be that AF_GPS would have been a way better choice. This > will sort itself out over time. > BT also fails to the same category. BT driver also just servers as HCI transport layer. Current implementation of closing device driver is not sufficient to really bring the device to rfkill mode. My point is from multi com devices. What vendor implements are proprietary HCI commands that brings device to rfkill mode, there is no standard. So in general you would need HCI parser similar to AT parser or NMEA GPS parser The rfkill event is transferred inside the transport not visible to device driver. In other words RFKILL is happening between device and application w/o kernel intervention. This is a problem since usually user application and kernel has to be somehow notified. Frankly I still don't understand what flow of how /dev/uevent is helpful here. Who is notifying whom about rfkill event. Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tomas, > >> > > we don't have a GPS subsystem, but even without it, I think this is a > >> > > good thing to have. > >> > > >> > GPS devices are usually serial devices. > >> > >> Yeah, this is interesting -- do we want something like /dev/urfkill > >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same > >> applies for 3G) can be controlled with rfkill? > > > > on one hand I think urfkill might be needed, on the other hand I think > > we should not do it at all. Currently I would think it is better to > > force the RFKILL integration in the kernel so that we have proper > > subsystem integration, or platform RFKILL switches or in cases like GPS > > and WWAN/3G it will be driver integration. For 3G we already have the > > hso.ko driver which has a killswitch and we just need to fix the other > > ones. I am actually looking into it, if this is possible without an AT > > parser inside the kernel. > > > > > So the GPS world is evolving right now and that everybody implements > > them as kernel-tty-passthrough pseudo driver and then a binary only > > daemon and then gpsd/gypsy on top of it will only survive for certain > > amount of time. The binary component will not get wide acceptance. And > > even if the binary only userspace component stays, we might still need a > > proper GPS subsystem since using TTY as pure transport is holding us > > back. Could be that AF_GPS would have been a way better choice. This > > will sort itself out over time. > > > > BT also fails to the same category. BT driver also just servers as HCI > transport layer. > Current implementation of closing device driver is not sufficient to > really bring the device to rfkill mode. My point is from multi com > devices. What vendor implements are proprietary HCI commands that > brings device to rfkill mode, there is no standard. So in general you > would need HCI parser similar to AT parser or NMEA GPS parser The > rfkill event is transferred inside the transport not visible to device > driver. > In other words RFKILL is happening between device and application w/o > kernel intervention. This is a problem since usually user application > and kernel has to be somehow notified. I have no idea what you are talking about here. The Bluetooth RFKILL does exactly the right thing. The driver gets the down callback and is responsible to bring the device down. It is expected that the radio will be brought down at that point. > Frankly I still don't understand what flow of how /dev/uevent is > helpful here. Who is notifying whom about rfkill event. Starting with 2.6.31 kernel we are using /dev/rfkill for notification about RFKILL state changes. Previously it was done via uevents, but that was more broken than helpful. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Aug 3, 2009 at 7:24 PM, Marcel Holtmann<marcel@holtmann.org> wrote: > Hi Tomas, > >> >> > > we don't have a GPS subsystem, but even without it, I think this is a >> >> > > good thing to have. >> >> > >> >> > GPS devices are usually serial devices. >> >> >> >> Yeah, this is interesting -- do we want something like /dev/urfkill >> >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same >> >> applies for 3G) can be controlled with rfkill? >> > >> > on one hand I think urfkill might be needed, on the other hand I think >> > we should not do it at all. Currently I would think it is better to >> > force the RFKILL integration in the kernel so that we have proper >> > subsystem integration, or platform RFKILL switches or in cases like GPS >> > and WWAN/3G it will be driver integration. For 3G we already have the >> > hso.ko driver which has a killswitch and we just need to fix the other >> > ones. I am actually looking into it, if this is possible without an AT >> > parser inside the kernel. >> >> > >> > So the GPS world is evolving right now and that everybody implements >> > them as kernel-tty-passthrough pseudo driver and then a binary only >> > daemon and then gpsd/gypsy on top of it will only survive for certain >> > amount of time. The binary component will not get wide acceptance. And >> > even if the binary only userspace component stays, we might still need a >> > proper GPS subsystem since using TTY as pure transport is holding us >> > back. Could be that AF_GPS would have been a way better choice. This >> > will sort itself out over time. >> > >> >> BT also fails to the same category. BT driver also just servers as HCI >> transport layer. >> Current implementation of closing device driver is not sufficient to >> really bring the device to rfkill mode. My point is from multi com >> devices. What vendor implements are proprietary HCI commands that >> brings device to rfkill mode, there is no standard. So in general you >> would need HCI parser similar to AT parser or NMEA GPS parser  The >> rfkill event is transferred inside the transport not visible to device >> driver. >> In other words RFKILL is happening between device and application w/o >> kernel intervention. This is a problem since usually user application >> and kernel has to be somehow notified. > > I have no idea what you are talking about here. The Bluetooth RFKILL > does exactly the right thing. The driver gets the down callback and is > responsible to bring the device down. It is expected that the radio will > be brought down at that point. Let say you have USB device with 2 ports BT and Wifi Closing prot just releases urbs but it doesn't tell to particular port to shut the radio it has no means for that., you have wifi running in parallel playing with the radio its BT/WIFI coexistent games it has no knowledge about rfkill event. In SDIO things are little better since you call sdio_disable_func() but you only guessing that device will interpret it as rfkill as well. >> Frankly I still don't understand what flow of how /dev/uevent is >> helpful here. Who is notifying whom about rfkill event. > > Starting with 2.6.31 kernel we are using /dev/rfkill for notification > about RFKILL state changes. Previously it was done via uevents, but that > was more broken than helpful. So how /dev/rfkill differs from /dev/urfkill ? Thanks Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Tomas, > >> >> > > we don't have a GPS subsystem, but even without it, I think this is a > >> >> > > good thing to have. > >> >> > > >> >> > GPS devices are usually serial devices. > >> >> > >> >> Yeah, this is interesting -- do we want something like /dev/urfkill > >> >> (cf. /dev/uinput), so that gpsd or whatever is controlling the GPS (same > >> >> applies for 3G) can be controlled with rfkill? > >> > > >> > on one hand I think urfkill might be needed, on the other hand I think > >> > we should not do it at all. Currently I would think it is better to > >> > force the RFKILL integration in the kernel so that we have proper > >> > subsystem integration, or platform RFKILL switches or in cases like GPS > >> > and WWAN/3G it will be driver integration. For 3G we already have the > >> > hso.ko driver which has a killswitch and we just need to fix the other > >> > ones. I am actually looking into it, if this is possible without an AT > >> > parser inside the kernel. > >> > >> > > >> > So the GPS world is evolving right now and that everybody implements > >> > them as kernel-tty-passthrough pseudo driver and then a binary only > >> > daemon and then gpsd/gypsy on top of it will only survive for certain > >> > amount of time. The binary component will not get wide acceptance. And > >> > even if the binary only userspace component stays, we might still need a > >> > proper GPS subsystem since using TTY as pure transport is holding us > >> > back. Could be that AF_GPS would have been a way better choice. This > >> > will sort itself out over time. > >> > > >> > >> BT also fails to the same category. BT driver also just servers as HCI > >> transport layer. > >> Current implementation of closing device driver is not sufficient to > >> really bring the device to rfkill mode. My point is from multi com > >> devices. What vendor implements are proprietary HCI commands that > >> brings device to rfkill mode, there is no standard. So in general you > >> would need HCI parser similar to AT parser or NMEA GPS parser The > >> rfkill event is transferred inside the transport not visible to device > >> driver. > >> In other words RFKILL is happening between device and application w/o > >> kernel intervention. This is a problem since usually user application > >> and kernel has to be somehow notified. > > > > I have no idea what you are talking about here. The Bluetooth RFKILL > > does exactly the right thing. The driver gets the down callback and is > > responsible to bring the device down. It is expected that the radio will > > be brought down at that point. > > Let say you have USB device with 2 ports BT and Wifi Closing prot > just releases urbs but it doesn't tell to particular port to shut the > radio it has no means for that., you have wifi running in parallel > playing with the radio its BT/WIFI coexistent games it has no > knowledge about rfkill event. In SDIO things are little better since > you call sdio_disable_func() but you only guessing that device will > interpret it as rfkill as well. this is a problem of the firmware inside the device. And if it is USB, it could just have proper vendor specific control URBs that allow you to control the radio RFKILL capabilities. If you happen to have a device that has no notion of RFKILL at all, then that is just bad luck. In embedded systems you can also have platform RFKILL switches that toggle directly the power state via a GPIO. This is what we call a hard killswitch. The subsystem integrated switches are softkill switches. > >> Frankly I still don't understand what flow of how /dev/uevent is > >> helpful here. Who is notifying whom about rfkill event. > > > > Starting with 2.6.31 kernel we are using /dev/rfkill for notification > > about RFKILL state changes. Previously it was done via uevents, but that > > was more broken than helpful. > > So how /dev/rfkill differs from /dev/urfkill ? I did explain that in the other email. We only have /dev/rfkill right now and it might stay this way. The /dev/urfkill would be a way to implement an RFKILL switch from within userspace. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/include/linux/rfkill.h b/include/linux/rfkill.h index 1020290..21ca51b 100644 --- a/include/linux/rfkill.h +++ b/include/linux/rfkill.h @@ -47,6 +47,7 @@ enum rfkill_type { RFKILL_TYPE_UWB, RFKILL_TYPE_WIMAX, RFKILL_TYPE_WWAN, + RFKILL_TYPE_GPS, NUM_RFKILL_TYPES, }; diff --git a/net/rfkill/core.c b/net/rfkill/core.c index 044de1c..dbeaf29 100644 --- a/net/rfkill/core.c +++ b/net/rfkill/core.c @@ -589,11 +589,13 @@ static const char *rfkill_get_type_str(enum rfkill_type type) return "wimax"; case RFKILL_TYPE_WWAN: return "wwan"; + case RFKILL_TYPE_GPS: + return "gps"; default: BUG(); } - BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_WWAN + 1); + BUILD_BUG_ON(NUM_RFKILL_TYPES != RFKILL_TYPE_GPS + 1); } static ssize_t rfkill_type_show(struct device *dev,
Althoug GPS is a technology w/o transmitting radio and thus not a primary candidate for rfkill switch, rfkill gives unified interface point for devices with wireless technology. The input key is not supplied as it is too be deprecated. Cc: johannes@sipsolutions.net Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> --- include/linux/rfkill.h | 1 + net/rfkill/core.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletions(-)