| Message ID | 3ace41890908261511i3056c049kca82831015ff2aa0@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: > (added list hal to To:, since it has become relevant; previous > exchanges of the thread on linux-wireless) > > On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote: >>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote: >>> >>>> > Or wait ... are you using compat-wireless? >>>> >>>> Yes, I am. I mentioned this and did wonder if the _backport/ part >>>> in /sys/class is important. >>> >>> Sorry, didn't see. >>> >>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to >>> some compat*.h but obviously the kernel won't ever call that notifier, >>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to >>> handle that -- it'll be working fine in a regular tree. >>> >>> Luis, the only way to handle that would be to manually call the PRE_UP >>> notifier from mac80211's subif_open() and if that returns an error >>> (warning: the calling convention is weird) return the error... that's >>> weird but would work. >>> >>> johannes >>> >> >> Hmm, got a bit side-tracked. But hal doesn't know the device having a >> killswitch is still wrong somewhere? >> (i.e. am wondering where we should advertise that ability, or how hal >> works that out) >> >> Hin-Tak >> > > I looked into hal and I can now say that it is certainly not > compat-wireless "rfkill_backport"-aware; apparently all it does is > monitoring entries under /sys/class that it knows about. I made a > quick hack: This is wrong, we just do not need to use rfkill_backport for sysfs stuff, consider sending me patch that removes that hunk for compat-wireless instead and test it. Luis -- 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 Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: > On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >> (added list hal to To:, since it has become relevant; previous >> exchanges of the thread on linux-wireless) >> >> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote: >>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote: >>>> >>>>> > Or wait ... are you using compat-wireless? >>>>> >>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part >>>>> in /sys/class is important. >>>> >>>> Sorry, didn't see. >>>> >>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to >>>> some compat*.h but obviously the kernel won't ever call that notifier, >>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to >>>> handle that -- it'll be working fine in a regular tree. >>>> >>>> Luis, the only way to handle that would be to manually call the PRE_UP >>>> notifier from mac80211's subif_open() and if that returns an error >>>> (warning: the calling convention is weird) return the error... that's >>>> weird but would work. >>>> >>>> johannes >>>> >>> >>> Hmm, got a bit side-tracked. But hal doesn't know the device having a >>> killswitch is still wrong somewhere? >>> (i.e. am wondering where we should advertise that ability, or how hal >>> works that out) >>> >>> Hin-Tak >>> >> >> I looked into hal and I can now say that it is certainly not >> compat-wireless "rfkill_backport"-aware; apparently all it does is >> monitoring entries under /sys/class that it knows about. I made a >> quick hack: > > This is wrong, we just do not need to use rfkill_backport for sysfs > stuff, consider sending me patch that removes that hunk for > compat-wireless instead and test it. > > Luis > Hmm, I did mention the other option - make rfkill_backport exposes its data structure as '/sys/class/rfkill' instead of '/sys/class/rfkill_backport'. Is there any reason why compat-wireless's rfkill_backport does not called itself 'rfkill' and unload and replace the old rfkill? That would be much neater, and userland tools like hal won't need to know anything about compat-wireless. Hin-Tak -- 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 Wed, Aug 26, 2009 at 3:55 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: > On Wed, Aug 26, 2009 at 11:28 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: >> On Wed, Aug 26, 2009 at 3:11 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >>> (added list hal to To:, since it has become relevant; previous >>> exchanges of the thread on linux-wireless) >>> >>> On Wed, Aug 26, 2009 at 5:29 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >>>> On Wed, Aug 26, 2009 at 3:34 PM, Johannes Berg<johannes@sipsolutions.net> wrote: >>>>> On Wed, 2009-08-26 at 13:33 +0000, Hin-Tak Leung wrote: >>>>> >>>>>> > Or wait ... are you using compat-wireless? >>>>>> >>>>>> Yes, I am. I mentioned this and did wonder if the _backport/ part >>>>>> in /sys/class is important. >>>>> >>>>> Sorry, didn't see. >>>>> >>>>> Anyway, that's pretty clearly the reason -- Luis added NETDEV_PRE_UP to >>>>> some compat*.h but obviously the kernel won't ever call that notifier, >>>>> so cfg80211 doesn't get a chance to reject the IFUP. No idea how to >>>>> handle that -- it'll be working fine in a regular tree. >>>>> >>>>> Luis, the only way to handle that would be to manually call the PRE_UP >>>>> notifier from mac80211's subif_open() and if that returns an error >>>>> (warning: the calling convention is weird) return the error... that's >>>>> weird but would work. >>>>> >>>>> johannes >>>>> >>>> >>>> Hmm, got a bit side-tracked. But hal doesn't know the device having a >>>> killswitch is still wrong somewhere? >>>> (i.e. am wondering where we should advertise that ability, or how hal >>>> works that out) >>>> >>>> Hin-Tak >>>> >>> >>> I looked into hal and I can now say that it is certainly not >>> compat-wireless "rfkill_backport"-aware; apparently all it does is >>> monitoring entries under /sys/class that it knows about. I made a >>> quick hack: >> >> This is wrong, we just do not need to use rfkill_backport for sysfs >> stuff, consider sending me patch that removes that hunk for >> compat-wireless instead and test it. >> >>  Luis >> > > Hmm, I did mention the other option - make rfkill_backport exposes its > data structure as '/sys/class/rfkill' instead of > '/sys/class/rfkill_backport'. Is there any reason why > compat-wireless's rfkill_backport  does not called itself 'rfkill' and > unload and replace the old rfkill? That would be much neater, and > userland tools like hal won't need to know anything about > compat-wireless. Johannes, did kernels < 2.6.31 have /sys/class/rfkill ? Luis -- 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 Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote:
> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ?
Yes, but I never understood why that matters. If you've got
compat-wireless "rfkill" loaded then the original rfkill can't be loaded
anyway. And their symbols would probably clash anyway if the original is
built in, in which case you can't use compat.
You haven't renamed cfg80211's sysfs either, so why rfkill?
johannes
On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote: > On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote: > >> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ? > > Yes, but I never understood why that matters. If you've got > compat-wireless "rfkill" loaded then the original rfkill can't be loaded > anyway. And their symbols would probably clash anyway if the original is > built in, in which case you can't use compat. > > You haven't renamed cfg80211's sysfs either, so why rfkill? > > johannes > There are a couple of wimax drivers which depends on rfkill... or bluetooth drivers? I think one likely reason is that there are valid situations or hardware combinations which requires having both of them loaded. (but that's a whole can of worms ) -- 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 Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: > On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote: >> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote: >> >>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ? >> >> Yes, but I never understood why that matters. If you've got >> compat-wireless "rfkill" loaded then the original rfkill can't be loaded >> anyway. And their symbols would probably clash anyway if the original is >> built in, in which case you can't use compat. >> >> You haven't renamed cfg80211's sysfs either, so why rfkill? >> >> johannes >> > > There are a couple of wimax drivers which depends on rfkill... or > bluetooth drivers? I think one likely reason is that there are valid > situations or hardware combinations which requires having both of them > loaded. (but that's a whole can of worms ) Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill won't load because of my modified compat-wireless rfkill_backport.ko which takes up /sys/class/rfkill rather than /sys/class/rfkill_backport . There's your reason from sysfs renaming. I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko needs it - maybe I had acpi unloaded as a side-effect also. I guess we'll need hal to treat /sys/class/rfkill_backport like /sys/class/rfkill then - will file a bug somewhere on freedesktop, although I hear hal is on its way out.... -- 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 31, 2009 at 11:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: > On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote: >>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote: >>> >>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ? >>> >>> Yes, but I never understood why that matters. If you've got >>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded >>> anyway. And their symbols would probably clash anyway if the original is >>> built in, in which case you can't use compat. >>> >>> You haven't renamed cfg80211's sysfs either, so why rfkill? >>> >>> johannes >>> >> >> There are a couple of wimax drivers which depends on rfkill... or >> bluetooth drivers? I think one likely reason is that there are valid >> situations or hardware combinations which requires having both of them >> loaded. (but that's a whole can of worms ) > > Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a > toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill > won't load because of my modified compat-wireless rfkill_backport.ko > which takes up /sys/class/rfkill rather than > /sys/class/rfkill_backport . There's your reason from sysfs renaming. > I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko > needs it - maybe I had acpi unloaded as a side-effect also. > > I guess we'll need hal to treat /sys/class/rfkill_backport like > /sys/class/rfkill  then - will file a bug somewhere on freedesktop, > although I hear hal is on its way out.... How many modules depend on rfkill, as with ssb maybe we should just add them all ? I'm not volunteering though, but just pointing out that if its not that many as with ssb perhaps its best to just add the other drivers. Luis -- 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 31, 2009 at 12:15 PM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: > On Mon, Aug 31, 2009 at 7:54 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: >> On Mon, Aug 31, 2009 at 11:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >>> On Thu, Aug 27, 2009 at 10:43 AM, Hin-Tak Leung<hintak.leung@gmail.com> wrote: >>>> On Thu, Aug 27, 2009 at 8:14 AM, Johannes Berg<johannes@sipsolutions.net> wrote: >>>>> On Wed, 2009-08-26 at 16:45 -0700, Luis R. Rodriguez wrote: >>>>> >>>>>> Johannes, did kernels < 2.6.31 have /sys/class/rfkill ? >>>>> >>>>> Yes, but I never understood why that matters. If you've got >>>>> compat-wireless "rfkill" loaded then the original rfkill can't be loaded >>>>> anyway. And their symbols would probably clash anyway if the original is >>>>> built in, in which case you can't use compat. >>>>> >>>>> You haven't renamed cfg80211's sysfs either, so why rfkill? >>>>> >>>>> johannes >>>>> >>>> >>>> There are a couple of wimax drivers which depends on rfkill... or >>>> bluetooth drivers? I think one likely reason is that there are valid >>>> situations or hardware combinations which requires having both of them >>>> loaded. (but that's a whole can of worms ) >>> >>> Argh, I just have a stacktrace after reboot - toshiba_acpi.ko (on a >>> toshiba laptop) requires the stock-kernel rfkill-* symbols, and rfkill >>> won't load because of my modified compat-wireless rfkill_backport.ko >>> which takes up /sys/class/rfkill rather than >>> /sys/class/rfkill_backport . There's your reason from sysfs renaming. >>> I wonder why/how I could unload rfkill.ko earlier, since the *_acpi.ko >>> needs it - maybe I had acpi unloaded as a side-effect also. >>> >>> I guess we'll need hal to treat /sys/class/rfkill_backport like >>> /sys/class/rfkill  then - will file a bug somewhere on freedesktop, >>> although I hear hal is on its way out.... >> >> How many modules depend on rfkill, as with ssb maybe we should just >> add them all ? I'm not volunteering though, but just pointing out that >> if its not that many as with ssb perhaps its best to just add the >> other drivers. >> >>  Luis >> > > for fedora 11's stock, (which probably have all the modules of any use) > #depmod -v | grep rfkill_register shows, besides drivers/net/wireless/* , > > kernel/drivers/net/usb/hso.ko > kernel/drivers/platform/x86/dell-laptop.ko > kernel/drivers/platform/x86/acer-wmi.ko > kernel/drivers/platform/x86/hp-wmi.ko > kernel/drivers/platform/x86/sony-laptop.ko > kernel/drivers/platform/x86/thinkpad_acpi.ko > kernel/drivers/platform/x86/toshiba_acpi.ko > kernel/net/wireless/cfg80211.ko OK not so bad except for: > kernel/net/wimax/wimax.ko That's touching another subsystem but we could technically merge wimax into compat-wireless if Inaky thinks that's a good idea. the point here is to unify anything that uses rfkill for backport usage. > If everything that depends on rkill is bundled with > compat-wireless, there is probablt no need for the symbol and sysfs > renaming hacks. Right which is why I think this may be reasonable to do. Any thoughts Inaky? Luis -- 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, 2009-08-31 at 13:25 -0600, Luis R. Rodriguez wrote: > OK not so bad except for: > > > kernel/net/wimax/wimax.ko > > That's touching another subsystem but we could technically merge wimax > into compat-wireless if Inaky thinks that's a good idea. the point > here is to unify anything that uses rfkill for backport usage. Oh boy, can of worms I have my own compat-wimax already, which already handles things for backwards compat (many #ifdef hacks to simplify life) and which is heavily used internally. I don't really know how much worth it might be and I know I don't have resources to support both. > > If everything that depends on rkill is bundled with > > compat-wireless, there is probablt no need for the symbol and sysfs > > renaming hacks. > > Right which is why I think this may be reasonable to do. Any thoughts Inaky? > Luis
Hi Luis, > > OK not so bad except for: > > > > > kernel/net/wimax/wimax.ko > > > > That's touching another subsystem but we could technically merge wimax > > into compat-wireless if Inaky thinks that's a good idea. the point > > here is to unify anything that uses rfkill for backport usage. > > Oh boy, can of worms > > I have my own compat-wimax already, which already handles things for > backwards compat (many #ifdef hacks to simplify life) and which is > heavily used internally. > > I don't really know how much worth it might be and I know I don't have > resources to support both. for the wireless-compat tree, I would just remove the RFKILL support for WiMAX. It is really not worth to support it. 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 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote: > Hi Luis, > >> > OK not so bad except for: >> > >> > > kernel/net/wimax/wimax.ko >> > >> > That's touching another subsystem but we could technically merge wimax >> > into compat-wireless if Inaky thinks that's a good idea. the point >> > here is to unify anything that uses rfkill for backport usage. >> >> Oh boy, can of worms >> >> I have my own compat-wimax already, which already handles things for >> backwards compat (many #ifdef hacks to simplify life) and which is >> heavily used internally. >> >> I don't really know how much worth it might be and I know I don't have >> resources to support both. > > for the wireless-compat tree, I would just remove the RFKILL support for > WiMAX. It is really not worth to support it. Works for me, we then still need to address (if we really care) the platform stuff. If someone is interested feel free to send patches to add those, I figure as long we get down to the latest supported stable kernel it should be good. The latest supported stable kernel is always on display on kernel,org, today being 2.6.27. Luis -- 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 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote: >> Hi Luis, >> >>> > OK not so bad except for: >>> > >>> > > kernel/net/wimax/wimax.ko >>> > >>> > That's touching another subsystem but we could technically merge wimax >>> > into compat-wireless if Inaky thinks that's a good idea. the point >>> > here is to unify anything that uses rfkill for backport usage. >>> >>> Oh boy, can of worms >>> >>> I have my own compat-wimax already, which already handles things for >>> backwards compat (many #ifdef hacks to simplify life) and which is >>> heavily used internally. >>> >>> I don't really know how much worth it might be and I know I don't have >>> resources to support both. >> >> for the wireless-compat tree, I would just remove the RFKILL support for >> WiMAX. It is really not worth to support it. > > Works for me, we then still need to address (if we really care) the > platform stuff. If someone is interested feel free to send patches to > add those, I figure as long we get down to the latest supported stable > kernel it should be good. The latest supported stable kernel is always > on display on kernel,org, today being 2.6.27. BTW inaky -- this is actually up to you, are you wiling to live with no rfkill for compat? Luis -- 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, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote: > On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: > > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote: > >> Hi Luis, > >> > >>> > OK not so bad except for: > >>> > > >>> > > kernel/net/wimax/wimax.ko > >>> > > >>> > That's touching another subsystem but we could technically merge wimax > >>> > into compat-wireless if Inaky thinks that's a good idea. the point > >>> > here is to unify anything that uses rfkill for backport usage. > >>> > >>> Oh boy, can of worms > >>> > >>> I have my own compat-wimax already, which already handles things for > >>> backwards compat (many #ifdef hacks to simplify life) and which is > >>> heavily used internally. > >>> > >>> I don't really know how much worth it might be and I know I don't have > >>> resources to support both. > >> > >> for the wireless-compat tree, I would just remove the RFKILL support for > >> WiMAX. It is really not worth to support it. > > > > Works for me, we then still need to address (if we really care) the > > platform stuff. If someone is interested feel free to send patches to > > add those, I figure as long we get down to the latest supported stable > > kernel it should be good. The latest supported stable kernel is always > > on display on kernel,org, today being 2.6.27. > > BTW inaky -- this is actually up to you, are you wiling to live with > no rfkill for compat? I don't really mind -- but it could be a problem for anyone trying to use it. Not that I recommend not being able to switch the radio off :) however, the WiMAX stack has APIs for it too, so at least there is a workaround. But remember, I won't be able to support it at all.
On Mon, Aug 31, 2009 at 4:10 PM, Inaky Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote: > On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote: >> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: >> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote: >> >> Hi Luis, >> >> >> >>> > OK not so bad except for: >> >>> > >> >>> > > kernel/net/wimax/wimax.ko >> >>> > >> >>> > That's touching another subsystem but we could technically merge wimax >> >>> > into compat-wireless if Inaky thinks that's a good idea. the point >> >>> > here is to unify anything that uses rfkill for backport usage. >> >>> >> >>> Oh boy, can of worms >> >>> >> >>> I have my own compat-wimax already, which already handles things for >> >>> backwards compat (many #ifdef hacks to simplify life) and which is >> >>> heavily used internally. >> >>> >> >>> I don't really know how much worth it might be and I know I don't have >> >>> resources to support both. >> >> >> >> for the wireless-compat tree, I would just remove the RFKILL support for >> >> WiMAX. It is really not worth to support it. >> > >> > Works for me, we then still need to address (if we really care) the >> > platform stuff. If someone is interested feel free to send patches to >> > add those, I figure as long we get down to the latest supported stable >> > kernel it should be good. The latest supported stable kernel is always >> > on display on kernel,org, today being 2.6.27. >> >> BTW inaky -- this is actually up to you, are you wiling to live with >> no rfkill for compat? > > I don't really mind -- but it could be a problem for anyone trying to > use it. Hm sure and there is still also the issue of users of wimax enabled on older kernels and using rfkill there. That is, users not using compat-wimax but using just compat-wireless and expecting rfkill to work smoothly between wimax and compat-wireless. I am not sure of the details of the platform rfkill drivers or how wimax or wireless drivers use these.. Perhaps there are no issues, I haven't really cared to look into it. > Not that I recommend not being able to switch the radio off :) > however, the WiMAX stack has APIs for it too, so at least there is a > workaround. You mean a way to rfkill without rfkill? > But remember, I won't be able to support it at all. To support what specifically? Luis -- 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, 2009-08-31 at 17:34 -0600, Luis R. Rodriguez wrote: > On Mon, Aug 31, 2009 at 4:10 PM, Inaky > Perez-Gonzalez<inaky.perez-gonzalez@intel.com> wrote: > > On Mon, 2009-08-31 at 17:05 -0600, Luis R. Rodriguez wrote: > >> On Mon, Aug 31, 2009 at 2:45 PM, Luis R. Rodriguez<mcgrof@gmail.com> wrote: > >> > On Mon, Aug 31, 2009 at 1:40 PM, Marcel Holtmann<marcel@holtmann.org> wrote: > >> >> Hi Luis, > >> >> > >> >>> > OK not so bad except for: > >> >>> > > >> >>> > > kernel/net/wimax/wimax.ko > >> >>> > > >> >>> > That's touching another subsystem but we could technically merge wimax > >> >>> > into compat-wireless if Inaky thinks that's a good idea. the point > >> >>> > here is to unify anything that uses rfkill for backport usage. > >> >>> > >> >>> Oh boy, can of worms > >> >>> > >> >>> I have my own compat-wimax already, which already handles things for > >> >>> backwards compat (many #ifdef hacks to simplify life) and which is > >> >>> heavily used internally. > >> >>> > >> >>> I don't really know how much worth it might be and I know I don't have > >> >>> resources to support both. > >> >> > >> >> for the wireless-compat tree, I would just remove the RFKILL support for > >> >> WiMAX. It is really not worth to support it. > >> > > >> > Works for me, we then still need to address (if we really care) the > >> > platform stuff. If someone is interested feel free to send patches to > >> > add those, I figure as long we get down to the latest supported stable > >> > kernel it should be good. The latest supported stable kernel is always > >> > on display on kernel,org, today being 2.6.27. > >> > >> BTW inaky -- this is actually up to you, are you wiling to live with > >> no rfkill for compat? > > > > I don't really mind -- but it could be a problem for anyone trying to > > use it. > > Hm sure and there is still also the issue of users of wimax enabled on > older kernels and using rfkill there. That is, users not using > compat-wimax but using just compat-wireless and expecting rfkill to > work smoothly between wimax and compat-wireless. > > I am not sure of the details of the platform rfkill drivers or how > wimax or wireless drivers use these.. Perhaps there are no issues, I > haven't really cared to look into it. > > > Not that I recommend not being able to switch the radio off :) > > however, the WiMAX stack has APIs for it too, so at least there is a > > workaround. > > You mean a way to rfkill without rfkill? the wimax_rfkill() call at the end gets at the same point as the rfkill call to toggle the radio. > > But remember, I won't be able to support it at all. > > To support what specifically? non-trivial bug reports. I always love to hear them, but I am really up to my neck. I just don't want to create the wrong expectations from users.
diff --git a/hald/linux/device.c b/hald/linux/device.c index 2eca1ef..61e94b7 100644 --- a/hald/linux/device.c +++ b/hald/linux/device.c @@ -4621,7 +4621,7 @@ static DevHandler dev_handler_power_supply = static DevHandler dev_handler_rfkill = { - .subsystem = "rfkill", + .subsystem = "rfkill_backport", .add = rfkill_add, .compute_udi = rfkill_compute_udi, .refresh = rfkill_refresh, ----------------- so that it looks for /sys/class/rfkill_backport instead of rfkill , and restarting hald, and lshal finally shows the killswitch. And NetworkManager also becomes aware of the rfkill state and no longer re-enable the device: --------------- Aug 26 22:08:36 localhost NetworkManager: <info> HAL disappeared . Aug 26 22:08:43 localhost NetworkManager: <info> HAL re-appeared Aug 26 22:08:43 localhost NetworkManager: <info> Found radio killswitch /org/freedesktop/Hal/devices/usb_device_bda_8197_00e04c000001_if0_rfkill_phy0_wlan Aug 26 22:09:16 localhost kernel: rtl8187: wireless radio switch turned off Aug 26 22:09:20 localhost NetworkManager: <info> Wireless now disabled by radio killswitch . Aug 26 22:13:21 localhost kernel: rtl8187: wireless radio switch turned on Aug 26 22:13:27 localhost NetworkManager: <info> Wireless now enabled by radio killswitch ------------- So, to summarise, from 2.6.31 onwards, cfg80211 should enforce the rfkill state from within the kernel no matter what hal/NM does; on non-bleeding edge systems, hal works out rfkill states from '/sys/class/rfkill' and let NM know. if you have a non-bleeding edge system but want to try compat-wireless anyway, hal simply doesn't know about rfkill_backport and NM re-enables the device when one plays with the rfkill switch. I guess there are two ways to go about this: (1) make compat-wireless unload and replace the as-shipped rfkill module completely and populate /sys/class/rfkill . (2) make hal monitor and treat /sys/class/rfkill_backport the same way and in addition to /sys/class/rfkill . So I went about (2) and just duplicated the rfkill entry like this, and it seems to work - anybody from hal wants to take this in? -------------- diff --git a/hald/linux/device.c b/hald/linux/device.c index 2eca1ef..feb198e 100644 --- a/hald/linux/device.c +++ b/hald/linux/device.c @@ -4628,6 +4628,15 @@ static DevHandler dev_handler_rfkill = .remove = dev_remove }; +static DevHandler dev_handler_rfkill_backport = +{ + .subsystem = "rfkill_backport", + .add = rfkill_add, + .compute_udi = rfkill_compute_udi, + .refresh = rfkill_refresh, + .remove = dev_remove +}; + static DevHandler dev_handler_scsi = { .subsystem = "scsi", .add = scsi_add, @@ -4817,6 +4826,7 @@ static DevHandler *dev_handlers[] = { &dev_handler_ps3_system_bus, &dev_handler_pseudo, &dev_handler_rfkill, + &dev_handler_rfkill_backport, &dev_handler_scsi, &dev_handler_scsi_generic, &dev_handler_scsi_host,