adding [email protected]
i expect somebody there may know a thing or two about the
proper way to do rfkill...
--
Len Brown, Intel Open Source Technology Center
On Fri, 12 Dec 2008, Henrique de Moraes Holschuh wrote:
> On Fri, 12 Dec 2008, Tony Vroon wrote:
> > On Thu, 2008-12-11 at 17:47 -0200, Henrique de Moraes Holschuh
> > wrote:
> > > I don't think so if you mean Gnome knowing what to do with EV_SW
> > > SW_RFKILL_ALL. That is not a report that radios got rfkilled, but
> > > rather a COMMAND to rfkill all radios.
> >
> > Right, so are we talking across purposes here?
>
> Probably. You still need to generate that SW_RFKILL_ALL input event
> anyway, btw, so that the rest of rfkill can know when the user wants
> all radios killed.
>
> > I want to report radio status to userland so NetworkManager can stop
> > helplessly flailing around asking me for a WPA2 password in a loop
> > if I kill the radios.
>
> That is a bug somewhere, and at first glance it looks to be either in
> the wireless network driver, wpa_supplicant, or network manager. It
> needs to be fixed, not worked around.
>
> What is the WLAN driver involved? Is it rfkill-aware?
>
> > What I have is an event-driven report that includes radio killswitch
> > status, HARD_BLOCKED or UNBLOCKED in rfkill terminology. There is no
> > SOFT_BLOCKED as I have no ability to turn individual radios on/off
> > in software.
>
> Whatever WLAN driver you use (which is not your Fujitsu Lifebook
> platform driver) should just get complete rfkill support, and Network
> Manager and wpa_supplicant have to do nonbraindamaged things when the
> radio is rfkilled. So let's ignore it.
>
> Just to make a point clear, you CAN ask HAL people to provide an OSD
> notification keyed on uevents sent by rfkill-input. It is completely
> correct to say "Radio kill switch active" and "Radio kill switch
> inactive" from some uevents rfkill-input generates (or will generate,
> I will check if I sent the patch already). It would still not mean
> all devices have been rfkilled, but at least it shows the truth from
> the point of view of the rfkill core and that has a higher chance of
> being true than keying OSD on input events that nobody might be
> listening to.
>
> I hope the above takes care of the "I want user feedback when the
> rfkill switch changes state" side. That leaves your question about
> attaching rfkill classes to phantom BT and WWAN devices inside your
> platform driver.
>
> BT and WWAN rfkilling are basically implemented in two possible ways,
> AFAIK:
>
> WARNING: THE STUFF BELOW IS FOR PLATFORM DRIVERS, NOT NETWORK DEVICE
> DRIVERS. NETWORK DEVICE DRIVERS DO IT SLIGHTLY DIFFERENT.
>
> 1. rfkill actualy is/looks like a hotplug/hotunplug operation
>
> 1a. You can do it at will (or you can do it at will except when the
> hardware switch is enforcing that they remain rfkilled):
>
> Attach rfkill classes to platform devices if you know this is
> the best way to software-command this functionality.
>
> Most notebooks go here for Bluetooth and WWAN. It is a pity
> Fujitsu Lifebooks don't.
>
> 1b. You cannot do it at will
>
> Attaching it to the rfkill core simply is not supported, and
> even if you force the issue with a weird toggle_radio(), you'd
> end up with a device that causes annoying behaviour every time
> you want to change its rfkill state. So, I cannot recommend
> it.
>
> The user knows if the radios are around or not from whatever
> hotplug subsystem they are tied to (PCI, USB), and that's what
> should be issuing events the user can see (only they will be of
> the "hardware connected/disconnected" sort, and not of the
> "radio killed" sort.
>
> 2. rfkill doesn't mess with the device existence, it just disables
> energy output:
>
> 2a. You can do it at will (or you can do it at will except when the
> hardware switch is enforcing that they remain rfkilled):
>
> You attach it to the rfkill core using a rfkill class, unless
> there is a better place to do it. Usually, there isn't.
>
> This is rare, as BT and WWAN are usually of type 1a, and WLAN
> is usually of type 2b.
>
> 2b. You cannot do it at will
>
> The rfkill class is to be attached to the device driver for that
> device, i.e. something in the bluetooth subsystem, USB subsystem
> or a wireless network driver.
>
> > Should I be creating individual Bluetooth/WLAN/WWAN rfkills that flip
> > between HARD_BLOCKED & UNBLOCKED with force status and return failure
> > for a radio state change attempt?
>
> Like I said, that's probably quite not nice for the user, and might
> cause very annoying behaviour on userspace applications. The rfkill
> core won't care for it either, but it won't break.
>
> However do NOT do it for WLAN. Almost every WLAN device knows quite
> well if it is being rfkilled or not by a hardware rfkill line, and it
> is their business to report it. And the wireless network drivers are
> being ported to connect to the rfkill core.
>
> > But perhaps code talks, let me just attach what I have right now. Both
>
> Not really in this case, no. It is not a case of coding it right,
> after all... I will look over the input device stuff in a separate
> reply.
>
> --
> "One disk to rule them all, One disk to find them. One disk to bring
> them all and in the darkness grind them. In the Land of Redmond
> where the shadows lie." -- The Silicon Valley Tarot
> Henrique Holschuh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Sat, Dec 13, 2008 at 08:55:13PM +0000, Tony Vroon wrote:
> There is actually a beautiful radio control device advertised in the
> DSDT as HID FUJ02E1 (internal name CMBT). Unfortunately this device does
> not actually appear to be present in the ACPI device list (while FUJ02B1
> and FUJ02E3 are, even without a driver loaded).
>
> I can get you the DSDT if it interests you.
Sure, I'd be interested in that.
--
Matthew Garrett | [email protected]
On Mon, 2008-12-15 at 12:59 -0500, Dan Williams wrote:
> > P.S. Did you get my e-mail about the Sierra Wireless MC8790?
>
> Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.
That uses USB interface 0 like on the other cards. On the MC8790 you
should be using USB interface 3. Unfortunately 0, 1 & 2 are duds that
just time out.
You can tell them apart from the "real" ones by them only having two
endpoints instead of three. I'm not sure whether this is a bug or a
feature yet.
> Dan
Regards,
Tony V.
On Sat, 2008-12-13 at 17:57 +0000, Matthew Garrett wrote:
> If there's no software control at all then I agree that providing an
> rfkill class here isn't appropriate.
Okay, thanks Matthew. For now that's where things stand, no software
control over the radios.
There is actually a beautiful radio control device advertised in the
DSDT as HID FUJ02E1 (internal name CMBT). Unfortunately this device does
not actually appear to be present in the ACPI device list (while FUJ02B1
and FUJ02E3 are, even without a driver loaded).
I can get you the DSDT if it interests you.
Regards,
Tony V.
> What is the WLAN driver involved? Is it rfkill-aware?
The driver is iwlagn, which does indeed notice that it is killed. This
information does not reach NetworkManager. Relevant log entries:
Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill Switch is On:
Dec 12 00:59:01 amalthea Kill switch must be turned off for wireless
networking to work.
[cutting relevant pieces of text together]
> > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > 1b. You cannot do it at will
> > Attaching it to the rfkill core simply is not supported
Okay, both Bluetooth & WWAN are USB devices following this terminology.
So the rfkill framework is not an appropriate tool for this job,
understood.
Len, I would still like to export the 3 values learned about in this
event to userspace. Is it alright for me to create 3 read-only files on
the platform device? (docked, lid, radios)
It would if anything simplify the code.
> However do NOT do it for WLAN. Almost every WLAN device knows quite
> well if it is being rfkilled or not by a hardware rfkill line, and it
> is their business to report it. And the wireless network drivers are
> being ported to connect to the rfkill core.
Okay.
Thanks,
Tony V.
On Tue, 2008-12-16 at 13:50 +0000, Tony Vroon wrote:
> On Mon, 2008-12-15 at 12:59 -0500, Dan Williams wrote:
> > > P.S. Did you get my e-mail about the Sierra Wireless MC8790?
> >
> > Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.
>
> That uses USB interface 0 like on the other cards. On the MC8790 you
> should be using USB interface 3. Unfortunately 0, 1 & 2 are duds that
> just time out.
> You can tell them apart from the "real" ones by them only having two
> endpoints instead of three. I'm not sure whether this is a bug or a
> feature yet.
Unfortunately, it might actually be any of the interfaces depending on
hotplug ordering. These days, having hal-info do static tagging based
on USB port numbering is somewhat broken; we need to do modem probing
(I've got that half-done) *and* start tagging the ports in the driver
itself. So you may be out of luck until then.
Dan
On Tue, 2008-12-16 at 10:12 +1030, Jonathan Woithe wrote:
> It's probably sensible for me to pick up on the next
> version of your patch.
There won't be a next version for a while. Please test the attached
version that uses simple platform files.
Regards,
Tony V.
On Sat, Dec 13, 2008 at 11:28:57AM -0200, Henrique de Moraes Holschuh wrote:
> > Len, I would still like to export the 3 values learned about in this
> > event to userspace. Is it alright for me to create 3 read-only files on
> > the platform device? (docked, lid, radios)
> > It would if anything simplify the code.
>
> FWIW, I think this is also the way to go. It is much easier for
> userspace to deal with sysfs attributes. HAL can deal with more
> complex stuff, but shell script writers often don't know how to, nor
> care to, deal with HAL.
I feel like I'm missing something here, but surely what we're talking
about is simply a single rfkill device that affects all radios and as
such should have a new RFKILL_TYPE_ALL type associated with it? I'd read
this as there being a software control that affected all radios. If
there's no software control at all then I agree that providing an rfkill
class here isn't appropriate.
--
Matthew Garrett | [email protected]
On Sat, 13 Dec 2008, Matthew Garrett wrote:
> On Sat, Dec 13, 2008 at 11:28:57AM -0200, Henrique de Moraes Holschuh wrote:
> > > Len, I would still like to export the 3 values learned about in this
> > > event to userspace. Is it alright for me to create 3 read-only files on
> > > the platform device? (docked, lid, radios)
> > > It would if anything simplify the code.
> >
> > FWIW, I think this is also the way to go. It is much easier for
> > userspace to deal with sysfs attributes. HAL can deal with more
> > complex stuff, but shell script writers often don't know how to, nor
> > care to, deal with HAL.
>
> I feel like I'm missing something here, but surely what we're talking
> about is simply a single rfkill device that affects all radios and as
> such should have a new RFKILL_TYPE_ALL type associated with it? I'd read
> this as there being a software control that affected all radios. If
> there's no software control at all then I agree that providing an rfkill
> class here isn't appropriate.
There isn't a "type all" rfkill class. I have patches that export the
rfkill core global states, and one of the global states looks like an
"all switch" indeed (the Emergency Power Off global state).
I did try an "one rfkill class for each type, and a master rfkill
class" approach a few months ago, and it didn't fly. I think I even
deleted it because it was too ugly to see the light of the day, or
something.
I will post what I have soon. I am not happy with it, but it might be
interesting to see if someone can come up with a better approach.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Sun, 14 Dec 2008, Dan Williams wrote:
> On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > > What is the WLAN driver involved? Is it rfkill-aware?
> > >
> > > The driver is iwlagn, which does indeed notice that it is killed.
> > > This information does not reach NetworkManager. Relevant log
> > > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > > off for wireless networking to work.
> >
> > Then, it is just a matter of time for it to be working correctly. In
> > fact, it might already be if you use wireless-testing and latest
> > network manager.
>
> If HAL's killswitch support doesn't know about the kernel killswitch
> device, or it cannot get the state of the killswitch, then certainly
> NetworkManager isn't going to know about it.
I see. I have added "up-to-date HAL also required" to my mental list of
stuff needed in userspace.
Thanks, Dan.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
On Sat, 13 Dec 2008, Tony Vroon wrote:
> > What is the WLAN driver involved? Is it rfkill-aware?
>
> The driver is iwlagn, which does indeed notice that it is killed.
> This information does not reach NetworkManager. Relevant log
> entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> off for wireless networking to work.
Then, it is just a matter of time for it to be working correctly. In
fact, it might already be if you use wireless-testing and latest
network manager.
Best not to mess with it, any workarounds one adds would just get in
the way in the future.
> [cutting relevant pieces of text together]
> > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > > 1b. You cannot do it at will
> > > Attaching it to the rfkill core simply is not supported
>
> Okay, both Bluetooth & WWAN are USB devices following this terminology.
> So the rfkill framework is not an appropriate tool for this job,
> understood.
>
> Len, I would still like to export the 3 values learned about in this
> event to userspace. Is it alright for me to create 3 read-only files on
> the platform device? (docked, lid, radios)
> It would if anything simplify the code.
FWIW, I think this is also the way to go. It is much easier for
userspace to deal with sysfs attributes. HAL can deal with more
complex stuff, but shell script writers often don't know how to, nor
care to, deal with HAL.
BTW, this also means that it is helpful to shell script writers if you
also export through read-only sysfs attributes the state of any input
devices generating EV_SW. The input layer makes it possible to query
the switch state easily... through IOCTL after you find out the
correct input device(s) to query. Which ain't easy for shell script,
and nobody wrote a "inputdev" helper in a proper language that can do
it, for shell script writers to call.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
> On Tue, 2008-12-16 at 10:12 +1030, Jonathan Woithe wrote:
> > It's probably sensible for me to pick up on the next
> > version of your patch.
>
> There won't be a next version for a while. Please test the attached
> version that uses simple platform files.
Ok, I'll see if I can get to this before the end of this week.
Regards
jonathan
On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> I plan to beat the shit out of the hal killswitch support pretty soon.
> AFAIK it still doesn't know about softblock, which is part of the whole
> reason for the rfkill rewrite in 2.6.26 anyway. It also doesn't yet
> (AFAIK) support uevents from killswitches either, which sucks.
Thanks Dan.
Could you let me know when you've committed this code so I have another
shot at implementing rfkill reporting in fujitsu-laptop?
> Dan
Regards,
Tony V.
P.S. Did you get my e-mail about the Sierra Wireless MC8790?
On Mon, 2008-12-15 at 09:53 -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 14 Dec 2008, Dan Williams wrote:
> > On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> > > On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > > > What is the WLAN driver involved? Is it rfkill-aware?
> > > >
> > > > The driver is iwlagn, which does indeed notice that it is killed.
> > > > This information does not reach NetworkManager. Relevant log
> > > > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > > > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > > > off for wireless networking to work.
> > >
> > > Then, it is just a matter of time for it to be working correctly. In
> > > fact, it might already be if you use wireless-testing and latest
> > > network manager.
> >
> > If HAL's killswitch support doesn't know about the kernel killswitch
> > device, or it cannot get the state of the killswitch, then certainly
> > NetworkManager isn't going to know about it.
>
> I see. I have added "up-to-date HAL also required" to my mental list of
> stuff needed in userspace.
I plan to beat the shit out of the hal killswitch support pretty soon.
AFAIK it still doesn't know about softblock, which is part of the whole
reason for the rfkill rewrite in 2.6.26 anyway. It also doesn't yet
(AFAIK) support uevents from killswitches either, which sucks.
Dan
Hi Tony
> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the .... out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway. It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
>
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?
This is to let you know that I'm still following this discussion but haven't
had anything sensible to add to the basic infrastructure issues being worked
through at present. It's probably sensible for me to pick up on the next
version of your patch.
Also, over the Christmas period (ie: after this week) my responses are
likely to be slow due to intermittant network access in that time.
I also haven't forgotten about getting you the DSDT from the S7020 - I just
haven't had a chance to get to that yet. I hope to get to this before the
end of the week.
Regards
jonathan
On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > What is the WLAN driver involved? Is it rfkill-aware?
> >
> > The driver is iwlagn, which does indeed notice that it is killed.
> > This information does not reach NetworkManager. Relevant log
> > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > off for wireless networking to work.
>
> Then, it is just a matter of time for it to be working correctly. In
> fact, it might already be if you use wireless-testing and latest
> network manager.
If HAL's killswitch support doesn't know about the kernel killswitch
device, or it cannot get the state of the killswitch, then certainly
NetworkManager isn't going to know about it.
Dan
> Best not to mess with it, any workarounds one adds would just get in
> the way in the future.
>
> > [cutting relevant pieces of text together]
> > > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > > > 1b. You cannot do it at will
> > > > Attaching it to the rfkill core simply is not supported
> >
> > Okay, both Bluetooth & WWAN are USB devices following this terminology.
> > So the rfkill framework is not an appropriate tool for this job,
> > understood.
> >
> > Len, I would still like to export the 3 values learned about in this
> > event to userspace. Is it alright for me to create 3 read-only files on
> > the platform device? (docked, lid, radios)
> > It would if anything simplify the code.
>
> FWIW, I think this is also the way to go. It is much easier for
> userspace to deal with sysfs attributes. HAL can deal with more
> complex stuff, but shell script writers often don't know how to, nor
> care to, deal with HAL.
>
> BTW, this also means that it is helpful to shell script writers if you
> also export through read-only sysfs attributes the state of any input
> devices generating EV_SW. The input layer makes it possible to query
> the switch state easily... through IOCTL after you find out the
> correct input device(s) to query. Which ain't easy for shell script,
> and nobody wrote a "inputdev" helper in a proper language that can do
> it, for shell script writers to call.
>
On Mon, 2008-12-15 at 17:14 +0000, Tony Vroon wrote:
> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the shit out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway. It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
>
> Thanks Dan.
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?
Yeah, though the HAL support will be coded to the kernel rfkill devices,
so if the platform or the wifi driver supports the kernel rfkill
interface, the HAL bits should work.
> P.S. Did you get my e-mail about the Sierra Wireless MC8790?
Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.
Dan