On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c as
follows:
Index:
Michael Buesch wrote:
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c
as follows:
Index:
Ivo van Doorn wrote:
Hi,
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to drivers/net/wireless/b43/rfkill.c
as follows:
Index:
On Tuesday 27 November 2007 19:33:41 Larry Finger wrote:
Ivo van Doorn wrote:
Hi,
On Monday 26 November 2007 23:15:53 Larry Finger wrote:
Based on the code in the rtx200 directories that has a call to
input_allocate_device() that was not
present in b43, I made a modification to
I have done a little looking into the problem of the radio LED not coming on,
and have found the
following:
[...]
Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger
file contain? Maybe the LED is registered in the wrong order and the
default name was NULL?
johannes
On Monday 26 November 2007 02:26:38 Larry Finger wrote:
Michael and Ivo,
I have done a little looking into the problem of the radio LED not coming on,
and have found the
following:
1. The call-back routine b43_rfkill_soft_toggle() is called once. When
called, rfkill.registered is
zero
Johannes Berg wrote:
I have done a little looking into the problem of the radio LED not coming
on, and have found the
following:
[...]
Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger
file contain? Maybe the LED is registered in the wrong order and the
default
Michael Buesch wrote:
Dunno. That's a poll-input-dev problem then. Do you have all poll-input
options enabled?
I think so. I have the following in .config:
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS
Do you have /sys/class/leds/b43-phyN:radio? If so, what does the trigger
File /sys/class/leds/b43-phy0\:rx/trigger contains
none ADP1-online BAT0-charging-or-full BAT0-charging BAT0-full [phy0rx]
phy0tx phy0assoc mmc0 rfkill0
and file /sys/class/leds/b43-phy0\:tx/trigger contains
LEDs work with Fedora Kernel 2.6.23.1-42.fc8.
LEDs NOT with Fedora Kernel 2.6.23.1-49.fc8
LEDs NOT with everything/2.6.24-rc2
LEDs NOT with wireless-2.6/2.6.24-rc3
I have the same settings in dot config as Larry does below and I have
the same info except for ...uevent has a power button but
Michael and Ivo,
I have done a little looking into the problem of the radio LED not coming on,
and have found the
following:
1. The call-back routine b43_rfkill_soft_toggle() is called once. When called,
rfkill.registered is
zero and the routine exits immediately.
2. The call-back routine
On Tuesday 20 November 2007 05:46:28 Larry Finger wrote:
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9414
[EMAIL PROTECTED] changed:
What|Removed |Added
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9414
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL
13 matches
Mail list logo
