* Re: Hardware button support for Wireless cards
From: Dan Williams @ 2006-05-15 14:37 UTC (permalink / raw)
To: Mark Wallis; +Cc: netdev, David Zeuthen
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAAWMRZS97Em0WybTChcxl4cAEALirLb4lrrkmZC6EvT+GpyAAAAABE9gAAEAAAALs6jNngvN9OooViTUM1CgIBAAAAAA==@serialmonkey.com>
On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> Hi everyone,
>
> Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> ACPI event so that the hardware button can be handled in userspace. This
> allows the user to basically do whatever they want when this button is
> pressed - including bringing down the wireless interface. The problem here
> is no distro's currently contain scripts to run from this event so for many
> users it just "doesn't work" without them manually having to write scripts
> to handle the ACPI even themselves.
>
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
> B. should we be firing an ACPI event and getting the distro's to add scripts
> so when this event is fired they bring down all the wireless interfaces.
(had this issue in the back of my head for a while already...)
Isn't the rf-kill switch specific to the manufacturer lots of times? Is
the switch connected directly to the card, or is it incumbent on the
driver to notice the event and disable the card via software? We need
to handle this for Bluetooth too, in situations where there's both a
bluetooth and an 802.11 card in the box. Does the rf-kill apply to
both? Or just to one?
WRT to disabling the radio, I'm not sure it makes a difference either
way. Hitting a button generally means "do this _NOW_", so it makes
sense for the driver to disable the radio and then send out the event.
Apps need to be able to deal with these resources going out from
underneath them, and I'm not sure it makes sense to wait around for some
scripts to run that just might possibly at some future point disable it,
but you're never sure.
In the end, an ACPI event is probably fine. I must stress that we NEED
to have a common event structure for this, such that every driver and
card presents the same interface. I don't want to have to write stuff
for each of 3 or 4 different cards to notice the rf-kill stuff. Witness
all the extra binaries that each driver has already for this sort of
thing. What interface does the ipw[2|3]xxx driver and hardware present?
What common bits can be drawn out from both?
Ideally, here's what would happen: the driver/card/whatever generates
an ACPI event, which is noticed by HAL. HAL sets a property on the
_exact_ device which the event is for, and propagates the signal out
over dbus. Any interested application can listen for, and respond to,
the rf-kill signal. (or, the event can be handled by acpid and the
distro can run scripts for it. 01dsk001. whatever)
But this means a few things. We need:
1) common interface/signal for _all_ cards and drivers
2) Enough information to identify which specific pci/pcmcia/etc device
the event is for (or system-wide?)
Dan
^ permalink raw reply
* Re: [RFC] changing value of NETDEV_ALIGN to cacheline size
From: Randy.Dunlap @ 2006-05-15 15:02 UTC (permalink / raw)
To: Christian Borntraeger; +Cc: netdev
In-Reply-To: <200605151408.29688.borntrae@de.ibm.com>
On Mon, 15 May 2006 14:08:29 +0200 Christian Borntraeger wrote:
> while digging through the alloc_netdev function I asked myself why there is a
> fixed alignment for netdevices. Is there a special reason for choosing 32? If
> yes, I suggest to add a comment to the definition.
>
> If not, I suspect cacheline alignment might be beneficial:
> struct net_device contains several variables which are cache aligned
> (poll_list, queue_lock .....). As far as I can see, the compiler tries to
> increase the size of the structure to make that possible, but expects the
> whole structure to be aligned to cache line size as well. With the current
> value for NETDEV_ALIGN we dont align "struct net_device" to the cache line,
> instead we align it to 32 bytes. That means that poll_list, queue_lock and
> friends are not always cache aligned, but 32 bytes aligned.
>
> The only reason why everything worked so far is the slab allocator design,
> which gives us a page aligned struct net_device in most cases. I think we
> should not rely on the behaviour of the memory allocator and use a different
> value for NETDEV_ALIGN instead. Any comments or corrections?
>
> cheers Christian
>
>
>
> The patch below is compile and boot tested on s390 and x86.
>
> Signed-off-by: Christian Borntraeger <borntrae@de.ibm.com>
>
> include/linux/netdevice.h | 2 +-
> net/core/dev.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
> ----------
>
> --- a/include/linux/netdevice.h 4 Apr 2006 07:25:47 -0000
> +++ b/include/linux/netdevice.h 15 May 2006 11:06:05 -0000
> @@ -504,7 +504,7 @@
> struct class_device class_dev;
> };
>
> -#define NETDEV_ALIGN 32
> +#define NETDEV_ALIGN L1_CACHE_BYTES
> #define NETDEV_ALIGN_CONST (NETDEV_ALIGN - 1)
I don't know about the fixed value of 32, but if this patch is
accepted, I'd prefer NETDEV_ALIGN_MASK instead of NETDEV_ALIGN_CONST.
> static inline void *netdev_priv(struct net_device *dev)
> --- a/net/core/dev.c 4 Apr 2006 07:25:50 -0000
> +++ b/net/core/dev.c 15 May 2006 11:06:05 -0000
> @@ -2986,7 +2986,7 @@
> struct net_device *dev;
> int alloc_size;
>
> - /* ensure 32-byte alignment of both the device and private area */
> + /* ensure cacheline alignment of both the device and private area */
> alloc_size = (sizeof(*dev) + NETDEV_ALIGN_CONST) & ~NETDEV_ALIGN_CONST;
> alloc_size += sizeof_priv + NETDEV_ALIGN_CONST;
---
~Randy
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Ivo van Doorn @ 2006-05-15 15:12 UTC (permalink / raw)
To: Dan Williams; +Cc: Mark Wallis, netdev, David Zeuthen
In-Reply-To: <1147703855.2193.47.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]
On Monday 15 May 2006 16:37, Dan Williams wrote:
> On Mon, 2006-05-15 at 22:57 +1000, Mark Wallis wrote:
> > Hi everyone,
> >
> > Currently, in our rt2x00 (using the devicescape stack) we are firing off an
> > ACPI event so that the hardware button can be handled in userspace. This
> > allows the user to basically do whatever they want when this button is
> > pressed - including bringing down the wireless interface. The problem here
> > is no distro's currently contain scripts to run from this event so for many
> > users it just "doesn't work" without them manually having to write scripts
> > to handle the ACPI even themselves.
> >
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> >
> > What are peoples thoughts here, should we
> >
> > A. be handling this within our drivers and doing "what the user expects" and
> > disabling the hardware radio, or
>
> > B. should we be firing an ACPI event and getting the distro's to add scripts
> > so when this event is fired they bring down all the wireless interfaces.
>
> (had this issue in the back of my head for a while already...)
>
> Isn't the rf-kill switch specific to the manufacturer lots of times? Is
> the switch connected directly to the card, or is it incumbent on the
> driver to notice the event and disable the card via software? We need
> to handle this for Bluetooth too, in situations where there's both a
> bluetooth and an 802.11 card in the box. Does the rf-kill apply to
> both? Or just to one?
The rt2x00 device itself does nothing when the button is pressed, it only
updates certain fields in a register to indicate the button is pressed.
The driver should read from the EEPROM if a hardware button is available,
after that it should poll the register to see if the button has been pressed,
and it is up to the driver what to do.
> WRT to disabling the radio, I'm not sure it makes a difference either
> way. Hitting a button generally means "do this _NOW_", so it makes
> sense for the driver to disable the radio and then send out the event.
> Apps need to be able to deal with these resources going out from
> underneath them, and I'm not sure it makes sense to wait around for some
> scripts to run that just might possibly at some future point disable it,
> but you're never sure.
Well I would think it is cleaner to inform userspace that the button is pressed
and let userspace sort out what exactly should happen.
But I doubt it will be a good idea when the driver is sending and event _and_
disabled the radio. It could be that the user wants something to be done
before the radio is being disabled.
> In the end, an ACPI event is probably fine. I must stress that we NEED
> to have a common event structure for this, such that every driver and
> card presents the same interface. I don't want to have to write stuff
> for each of 3 or 4 different cards to notice the rf-kill stuff. Witness
> all the extra binaries that each driver has already for this sort of
> thing. What interface does the ipw[2|3]xxx driver and hardware present?
> What common bits can be drawn out from both?
>
> Ideally, here's what would happen: the driver/card/whatever generates
> an ACPI event, which is noticed by HAL. HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus. Any interested application can listen for, and respond to,
> the rf-kill signal. (or, the event can be handled by acpid and the
> distro can run scripts for it. 01dsk001. whatever)
This idea sounds good, but is ACPI the thing to be used.
Escpially since ACPI is a bit architectures dependent.
And the solution should be supported on various architectures.
> But this means a few things. We need:
>
> 1) common interface/signal for _all_ cards and drivers
> 2) Enough information to identify which specific pci/pcmcia/etc device
> the event is for (or system-wide?)
system-wide would not be a good idea, we need something to determine which
driver exactly has triggered the event. Some laptops have several hardware buttons
1 for Bluetooth and 1 for Wifi for example.
So we could just pass the name the driver has created for that button to userspace.
At least that is a similar approach to ACPI where the class, bid and name fields
are all names set by the driver.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Jason Lunz @ 2006-05-15 15:27 UTC (permalink / raw)
To: netdev
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAAC4AAAAAAAAAWMRZS97Em0WybTChcxl4cAEALirLb4lrrkmZC6EvT+GpyAAAAABE9gAAEAAAALs6jNngvN9OooViTUM1CgIBAAAAAA==@serialmonkey.com>
mwallis@serialmonkey.com said:
> Some people are saying that instead of throwing and ACPI event we should be
> either use hotplug or internally just disable the radio and somehow inform
> the dscape stack that the radio has been disabled.
>
> What are peoples thoughts here, should we
>
> A. be handling this within our drivers and doing "what the user expects" and
> disabling the hardware radio, or
On my HP laptop with bcm43xx wireless, the button disables the radio in
HARDWARE, and afaict the driver has no idea about it. The driver notices
that it's not connected and happily starts scanning again, unaware that
anything is wrong.
This is actually quite nice for testing roaming setups. You can "roam"
in and out of range by toggling the button.
The other laptop in the house has a physical _switch_, which implies
that it too cuts off the radio in hardware (though I haven't
investigated this, so I'm only speculating).
So if there's any desire for consistency of wireless button support,
then I think the software-controlled ones should always shut off the
radio, and optionally inform userspace or the wireless stack using some
event mechanism.
What is the purpose of these switches anyway? Power saving? Or is it for
situations like an airplane or hospital where you want to be sure your
wireless won't cause any interference? If the latter, than that also
argues for always shutting off the radio immediately.
Jason
^ permalink raw reply
* Re: [PATCH] pcnet32.c: modify RX ring size through module parameter
From: Don Fry @ 2006-05-15 15:54 UTC (permalink / raw)
To: Wen Hsin Chang; +Cc: davem, netdev, tsbogend
In-Reply-To: <4467F63E.5060401@tw.ibm.com>
I have several problems with this patch. First, it assumes you only have
one device or you want all devices to operate with the same receive ring
size. (use module_param_array like full_duplex or options).
Second, the mininum number of descriptors should be 4 not 2, or the
loopback test will look past the end of the receive ring looking for
status to change, and then try and pick up an skb pointer past the end of
the array and try to dereference it.
Either fix the loopback test to work with the minimum number of tx and rx
descriptors instead of the hard coded 4, or make the minimum rx ring
size be 4. numbuffs = min(4 , min(lp->tx_ring_size, lp->rx_ring_size));
Another nit is the description says it is the "RX Ring Buffer Size" which
might be misunderstood as the size of the receive buffer, not the size of
the receive descriptor ring. ("RX Ring Size" would be better).
Lastly, the patch also will not apply against pcnet32.c in mainline
2.6.17-rc4 due to whitespace changes.
On Mon, May 15, 2006 at 11:32:14AM +0800, Wen Hsin Chang wrote:
> This patch is created from pcnet32.c v1.32. it will allow users to
> specify RX ring size upon module
> insertion via module parameter 'rx_log_size'. This is needed in some
> cases where too small the rx ring
> size will cause RX errors upon remote installation via pcnet32 NIC card.
>
> Signed-off-by: Wen Hsin Chang <whchang@tw.ibm.com>
--
Don Fry
brazilnut@us.ibm.com
^ permalink raw reply
* Re: [PATCH] pcnet32.c: modify RX ring size through module parameter
From: Jon Mason @ 2006-05-15 15:58 UTC (permalink / raw)
To: Wen Hsin Chang; +Cc: davem, netdev, tsbogend, brazilnut
In-Reply-To: <4467F63E.5060401@tw.ibm.com>
Why is this necessary? There is already an ethtool function to set
the rx ring size (pcnet32_set_ringparam). Since module parameters
are being phased out in favor of the ethtool functions, why not use
the existing ethtool infrastructure for this?
Thanks,
Jon
On Mon, May 15, 2006 at 11:32:14AM +0800, Wen Hsin Chang wrote:
> This patch is created from pcnet32.c v1.32. it will allow users to
> specify RX ring size upon module
> insertion via module parameter 'rx_log_size'. This is needed in some
> cases where too small the rx ring
> size will cause RX errors upon remote installation via pcnet32 NIC card.
>
> Signed-off-by: Wen Hsin Chang <whchang@tw.ibm.com>
> ----------------------------------------------------------------------------------------------------
>
> --- a/drivers/net/pcnet32.c 2006-03-30 09:49:10.000000000 +0800
> +++ b/drivers/net/pcnet32.c 2006-05-15 11:14:45.000000000 +0800
> @@ -93,6 +93,9 @@ static struct net_device *pcnet32_dev;
> static int max_interrupt_work = 2;
> static int rx_copybreak = 200;
>
> +/* Module parameter to specify RX ring size at module insertion */
> +static int rx_log_size = 0;
> +
> #define PCNET32_PORT_AUI 0x00
> #define PCNET32_PORT_10BT 0x01
> #define PCNET32_PORT_GPSI 0x02
> @@ -1264,7 +1267,10 @@ pcnet32_probe1(unsigned long ioaddr, int
> lp->name = chipname;
> lp->shared_irq = shared;
> lp->tx_ring_size = TX_RING_SIZE; /* default tx ring size */
> - lp->rx_ring_size = RX_RING_SIZE; /* default rx ring size */
> + if (!rx_log_size)
> + lp->rx_ring_size = RX_RING_SIZE; /* default rx ring size */
> + else
> + lp->rx_ring_size = (1 << (rx_log_size));
> lp->tx_mod_mask = lp->tx_ring_size - 1;
> lp->rx_mod_mask = lp->rx_ring_size - 1;
> lp->tx_len_bits = (PCNET32_LOG_TX_BUFFERS << 12);
> @@ -2707,6 +2713,11 @@ module_param(tx_start_pt, int, 0);
> MODULE_PARM_DESC(tx_start_pt, DRV_NAME " transmit start point (0-3)");
> module_param(pcnet32vlb, int, 0);
> MODULE_PARM_DESC(pcnet32vlb, DRV_NAME " Vesa local bus (VLB) support
> (0/1)");
> +
> +/* Module parameter to specify RX ring size at module insertion */
> +module_param(rx_log_size, int, 0);
> +MODULE_PARM_DESC(rx_log_size, DRV_NAME " RX Ring Buffer Size (log_2
> #BUF) ");
> +
> module_param_array(options, int, NULL, 0);
> MODULE_PARM_DESC(options, DRV_NAME " initial option setting(s) (0-15)");
> module_param_array(full_duplex, int, NULL, 0);
> @@ -2731,6 +2742,12 @@ static int __init pcnet32_init_module(vo
>
> if ((tx_start_pt >= 0) && (tx_start_pt <= 3))
> tx_start = tx_start_pt;
> +
> + /* validating rx_log_size */
> + if ((rx_log_size <= 0) ||
> + (rx_log_size > PCNET32_LOG_MAX_RX_BUFFERS))
> + rx_log_size = 0;
> +
>
> /* find the PCI devices */
> if (!pci_module_init(&pcnet32_driver))
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Michael Buesch @ 2006-05-15 16:01 UTC (permalink / raw)
To: Jason Lunz; +Cc: netdev
In-Reply-To: <e4a6lq$g5v$1@sea.gmane.org>
On Monday 15 May 2006 17:27, you wrote:
> mwallis@serialmonkey.com said:
> > Some people are saying that instead of throwing and ACPI event we should be
> > either use hotplug or internally just disable the radio and somehow inform
> > the dscape stack that the radio has been disabled.
> >
> > What are peoples thoughts here, should we
> >
> > A. be handling this within our drivers and doing "what the user expects" and
> > disabling the hardware radio, or
>
> On my HP laptop with bcm43xx wireless, the button disables the radio in
> HARDWARE, and afaict the driver has no idea about it. The driver notices
> that it's not connected and happily starts scanning again, unaware that
> anything is wrong.
There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
some "Radio is hardware-disabled" state. We currently don't use that flag
correctly in the driver. Could you please assist me on testing if your switch
actually toggles the bit?
I think best place for this would be on irc.freenode.net #bcm-users
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Pekka Savola @ 2006-05-15 16:05 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev
In-Reply-To: <Pine.SOC.4.61.0605150909510.29527@math.ut.ee>
On Mon, 15 May 2006, Meelis Roos wrote:
> On my home 6to4 gw, ipv6 routing seems to be broken and everything is sent to
> 6to4 tunnel (the default route). It worked with fine for a long time and with
> 2.6.17-rc2-g4d5c34ec and it's broken with vmlinuz-2.6.17-rc3-g3cd73eed and
> 2.6.17-rc4-g9be2f7c3 (yesterdays kernel).
...
> vaarikas:~# ip -6 route
> 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480
> advmss 1420 hoplimit 4294967295
You're using the wrong prefix length. The right one is /16. Does
that work?
Maybe the 6to4 hack which didn't heed routing table (so either prefix
length was OK) was removed or changed...
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: David Zeuthen @ 2006-05-15 16:19 UTC (permalink / raw)
To: Dan Williams; +Cc: Mark Wallis, netdev
In-Reply-To: <1147703855.2193.47.camel@localhost.localdomain>
On Mon, 2006-05-15 at 10:37 -0400, Dan Williams wrote:
> Ideally, here's what would happen: the driver/card/whatever generates
> an ACPI event, which is noticed by HAL. HAL sets a property on the
> _exact_ device which the event is for, and propagates the signal out
> over dbus. Any interested application can listen for, and respond to,
> the rf-kill signal. (or, the event can be handled by acpid and the
> distro can run scripts for it. 01dsk001. whatever)
Yes, I agree this needs to happen in user space partly because it's
policy even though I can only come up with crack reasons on why you
wouldn't want to turn off the radio when the button is pressed.
However, I suppose we need to do it in user space for some laptops
anyway since I'm not sure the "RF Kill Switch" button and the networking
hardware may be related; see below.
>
> But this means a few things. We need:
>
> 1) common interface/signal for _all_ cards and drivers
Right, this would be nice. This is sorta like the mess that is hotkeys
on laptops. We sorta deal with those in HAL but it's a lot of ugly code
to present a sane abstract interface to user space.
> 2) Enough information to identify which specific pci/pcmcia/etc device
> the event is for (or system-wide?)
No, I'm not really sure we need to know exactly what device this is
triggered for and I'm not even sure that the kernel can figure this out
anyway: the RF Kill buttons may be implemented as a USB HID device for
example which may have little relation to the hardware. Another example
is where the user is using a USB or PC Card Wifi adapter instead of the
built-in Wifi. We want to turn off the radio on the USB or PC Card in
these cases too.
So what we need from user space is basically just an event saying "RF
Kill button pressed" perhaps with some detail such as 'bluetooth' or
'wifi' depending on the graphics of the button (no, I'm not kidding).
It would also be nice with some way to query state, e.g. "is the button
pressed or not" if the hardware supports this. So, I think perhaps it
may make sense to model this as an input device. Then we can simply
query this input device from user space (in HAL) and emit the right
events and provide an interface to query whether the button is pressed
or not [1]. Specifically, on startup, NetworkManager would just ask HAL
whether the button is pressed or not (if the hardware supports it) and
do the right thing, e.g. selectively suspend all networking devices with
a radio via the power/state file in sysfs which will turn off the radio.
When the user presses the button, NetworkManager enables / disables the
device [2] and so on.
Hope this helps.
David
[1] : we do the same thing for other buttons in HAL; e.g. the power
button on some Powerbooks.
[2] : this raises another problem. What happens to class devices when a
bus device is turned off (e.g. selective suspend). For example, does the
class device /sys/class/net/eth0 go away when I put the physical to
sleep via the /sys/class/net/eth0/device/power/state file?
Maybe off topic, but what happens in general? For example what happens
when I selectively suspend a USB harddisk enclosure, does /sys/block/sda
go away? If it doesn't, does '# touch /dev/sda' wake it up? (it probably
shouldn't)...
This kind of stuff needs to be precisely defined, yes? Is it already
defined?
^ permalink raw reply
* [PATCH for 2.6.17] [1/5] x86_64: Check for bad dma address in b44 1GB DMA workaround
From: Andi Kleen @ 2006-05-15 16:19 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev
Needed for interaction with the nommu code in x86-64 which
will return bad_dma_address if the address exceeds dma_mask.
Cc: netdev@vger.kernel.org
Signed-off-by: Andi Kleen <ak@suse.de>
---
drivers/net/b44.c | 28 ++++++++++++++++++----------
1 files changed, 18 insertions(+), 10 deletions(-)
Index: linux/drivers/net/b44.c
===================================================================
--- linux.orig/drivers/net/b44.c
+++ linux/drivers/net/b44.c
@@ -650,9 +650,11 @@ static int b44_alloc_rx_skb(struct b44 *
/* Hardware bug work-around, the chip is unable to do PCI DMA
to/from anything above 1GB :-( */
- if (mapping + RX_PKT_BUF_SZ > B44_DMA_MASK) {
+ if (dma_mapping_error(mapping) ||
+ mapping + RX_PKT_BUF_SZ > B44_DMA_MASK) {
/* Sigh... */
- pci_unmap_single(bp->pdev, mapping, RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp->pdev, mapping, RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
skb = __dev_alloc_skb(RX_PKT_BUF_SZ,GFP_DMA);
if (skb == NULL)
@@ -660,8 +662,10 @@ static int b44_alloc_rx_skb(struct b44 *
mapping = pci_map_single(bp->pdev, skb->data,
RX_PKT_BUF_SZ,
PCI_DMA_FROMDEVICE);
- if (mapping + RX_PKT_BUF_SZ > B44_DMA_MASK) {
- pci_unmap_single(bp->pdev, mapping, RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
+ if (dma_mapping_error(mapping) ||
+ mapping + RX_PKT_BUF_SZ > B44_DMA_MASK) {
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp->pdev, mapping, RX_PKT_BUF_SZ,PCI_DMA_FROMDEVICE);
dev_kfree_skb_any(skb);
return -ENOMEM;
}
@@ -967,9 +971,10 @@ static int b44_start_xmit(struct sk_buff
}
mapping = pci_map_single(bp->pdev, skb->data, len, PCI_DMA_TODEVICE);
- if (mapping + len > B44_DMA_MASK) {
+ if (dma_mapping_error(mapping) || mapping + len > B44_DMA_MASK) {
/* Chip can't handle DMA to/from >1GB, use bounce buffer */
- pci_unmap_single(bp->pdev, mapping, len, PCI_DMA_TODEVICE);
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp->pdev, mapping, len, PCI_DMA_TODEVICE);
bounce_skb = __dev_alloc_skb(TX_PKT_BUF_SZ,
GFP_ATOMIC|GFP_DMA);
@@ -978,8 +983,9 @@ static int b44_start_xmit(struct sk_buff
mapping = pci_map_single(bp->pdev, bounce_skb->data,
len, PCI_DMA_TODEVICE);
- if (mapping + len > B44_DMA_MASK) {
- pci_unmap_single(bp->pdev, mapping,
+ if (dma_mapping_error(mapping) || mapping + len > B44_DMA_MASK) {
+ if (!dma_mapping_error(mapping))
+ pci_unmap_single(bp->pdev, mapping,
len, PCI_DMA_TODEVICE);
dev_kfree_skb_any(bounce_skb);
goto err_out;
@@ -1203,7 +1209,8 @@ static int b44_alloc_consistent(struct b
DMA_TABLE_BYTES,
DMA_BIDIRECTIONAL);
- if (rx_ring_dma + size > B44_DMA_MASK) {
+ if (dma_mapping_error(rx_ring_dma) ||
+ rx_ring_dma + size > B44_DMA_MASK) {
kfree(rx_ring);
goto out_err;
}
@@ -1229,7 +1236,8 @@ static int b44_alloc_consistent(struct b
DMA_TABLE_BYTES,
DMA_TO_DEVICE);
- if (tx_ring_dma + size > B44_DMA_MASK) {
+ if (dma_mapping_error(tx_ring_dma) ||
+ tx_ring_dma + size > B44_DMA_MASK) {
kfree(tx_ring);
goto out_err;
}
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Jouni Malinen @ 2006-05-15 16:20 UTC (permalink / raw)
To: Ivo van Doorn; +Cc: Dan Williams, Mark Wallis, netdev, David Zeuthen
In-Reply-To: <200605151712.23639.IvDoorn@gmail.com>
On Mon, May 15, 2006 at 05:12:20PM +0200, Ivo van Doorn wrote:
> Well I would think it is cleaner to inform userspace that the button is pressed
> and let userspace sort out what exactly should happen.
> But I doubt it will be a good idea when the driver is sending and event _and_
> disabled the radio. It could be that the user wants something to be done
> before the radio is being disabled.
Some hardware designs disable the radio in hardware, some don't.. In
other words, the behavior would not be consistent between hardware
designs unless the radio would be disabled unconditionally in
software-processed case. I would like to be able to trust on the
rfkill to really kill the radio regardless of whether the user space
mechanism is in place or not, i.e., I see this as a function that can be
used to disable radio in environments were use of wireless devices is
not allowed for some reason.
Sending an event to user space would be a good additional indication
that the radio was disabled. If user space wants to do something first,
I would think that doing this with full software control (i.e., not
depending on any particular hardware button and just having a UI
mechanism for triggering this) would allow more consistent behavior.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: [PATCH 4/6] myri10ge - First half of the driver
From: Lee Revell @ 2006-05-15 17:02 UTC (permalink / raw)
To: Brice Goglin; +Cc: Francois Romieu, netdev, LKML, Andrew J. Gallatin
In-Reply-To: <4463CE88.20301@myri.com>
On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote:
> Francois Romieu wrote:
> >
> >> + spin_lock(&mgp->cmd_lock);
> >> + response->result = 0xffffffff;
> >> + mb();
> >> + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf));
> >> +
> >> + /* wait up to 2 seconds */
> >>
> >
> > You must not hold a spinlock for up to 2 seconds.
> >
>
> We are working on reducing the delay to about 15ms. It only occurs when
> the driver is loaded or the link brought up.
I think 15ms is quite a long time to hold a spinlock also - most
spinlocks in the kernel are held for less than 500 microseconds.
Can't you use a mutex?
Lee
^ permalink raw reply
* Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
From: Meelis Roos @ 2006-05-15 17:29 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <446765CC.8020500@trash.net>
>> Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently
>> compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables
>> userland binary is from the latest Debian unstable (1.3.3-2).
>>
>> The symptoms: iptables usually just tells Invalid Argument on any
>> modification attempt. I'm trying to set up a simple one-rule NAT for test:
>> iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT --to 10.0.0.1
>> and it usually fails but has succeeded 2 times (I now have 2 rules of
>> this kind and they seem to just wotk once set up). Trying to delete the
>> second rule (either by replacing -A with -D or using just -D 2) gives
>> the same error.
>
>
> This should already be fixed in -rc4.
Unfortunately it was still there with yesterdays rc4+git.
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-15 17:30 UTC (permalink / raw)
To: Pekka Savola; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0605151904110.12081@netcore.fi>
>> vaarikas:~# ip -6 route
>> 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480
>> advmss 1420 hoplimit 4294967295
>
> You're using the wrong prefix length. The right one is /16. Does that work?
Will try soon today. But the other routes had mor specific masks anyway -
/64 and /128, so why should it change anything?
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: ipv6 routing broken in 2.6.17-rc3,4
From: Meelis Roos @ 2006-05-15 17:38 UTC (permalink / raw)
To: Pekka Savola; +Cc: netdev
In-Reply-To: <Pine.LNX.4.64.0605151904110.12081@netcore.fi>
>> vaarikas:~# ip -6 route
>> 2002:5283:297e::/48 dev tun6to4 metric 256 expires 21332659sec mtu 1480
>> advmss 1420 hoplimit 4294967295
>
> You're using the wrong prefix length. The right one is /16. Does that work?
Changed tun6to4 to 2002::/16, still the same (packets for eth0 and the
unreachable destination still go to tun6to4).
# ip -6 route
::/96 via :: dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295
unreachable 2001:7a8:1:5::14 dev lo metric 1024 expires 21334363sec error -101 mtu 16436 advmss 16376 hoplimit 4294967295
2002:5283:2811:2::/64 dev eth0 metric 256 expires 21334342sec mtu 1500 advmss 1440 hoplimit 4294967295
2002::/16 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295
2000::/3 via ::192.88.99.1 dev tun6to4 metric 1 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295
fe80::/64 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295
ff00::/8 dev eth1 metric 256 expires 21334336sec mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev tun6to4 metric 256 expires 21334342sec mtu 1480 advmss 1420 hoplimit 4294967295
ff00::/8 dev eth0 metric 256 expires 21332676sec mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo proto none metric -1 error -101 hoplimit 255
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: [PATCH 4/6] myri10ge - First half of the driver
From: Brice Goglin @ 2006-05-15 17:39 UTC (permalink / raw)
To: Lee Revell; +Cc: Francois Romieu, netdev, LKML, Andrew J. Gallatin
In-Reply-To: <1147712555.27252.269.camel@mindpipe>
Lee Revell wrote:
> On Fri, 2006-05-12 at 01:53 +0200, Brice Goglin wrote:
>
>> Francois Romieu wrote:
>>
>>>> + spin_lock(&mgp->cmd_lock);
>>>> + response->result = 0xffffffff;
>>>> + mb();
>>>> + myri10ge_pio_copy((void __iomem *) cmd_addr, buf, sizeof (*buf));
>>>> +
>>>> + /* wait up to 2 seconds */
>>>>
>>>>
>>> You must not hold a spinlock for up to 2 seconds.
>>>
>>>
>> We are working on reducing the delay to about 15ms. It only occurs when
>> the driver is loaded or the link brought up.
>>
>
> I think 15ms is quite a long time to hold a spinlock also - most
> spinlocks in the kernel are held for less than 500 microseconds.
>
> Can't you use a mutex?
>
It looks like rtnl_lock protects us here. We are working on it.
Brice
^ permalink raw reply
* Re: [PATCH wireless-dev] d80211: Don't discriminate against 802.11b drivers
From: Michael Wu @ 2006-05-15 17:19 UTC (permalink / raw)
To: Jiri Benc; +Cc: John W. Linville, Jouni Malinen, netdev, jkmaline
In-Reply-To: <20060515133725.3df090af@griffin.suse.cz>
On Monday 15 May 2006 07:37, Jiri Benc wrote:
> This issue can be easily solved by not masking hw_modes by
> valid_hw_modes in ieee80211_ioctl_prism2_param and
> ieee80211_precalc_modes. Just check (hw_modes & valid_hw_modes) instead
> of hw_modes in ieee80211_sta_scan_timer.
>
> And yes, hw_modes is a confusing name. It should be named
> hw_modes_mask_disabled_by_user or so. Maybe at least some better comment
> about this in ieee80211_i.h won't be a bad idea.
>
Okay, how about this? Instead of adding valid_hw_modes, I added enabled_modes,
and replaced all instances of local->hw_modes with local->enabled_modes.
local->hw_modes now really means what modes are supported by the hardware.
Signed-off-by: Michael Wu <flamingice@sourmilk.net>
diff --git a/net/d80211/ieee80211.c b/net/d80211/ieee80211.c
index ffb7985..135db24 100644
--- a/net/d80211/ieee80211.c
+++ b/net/d80211/ieee80211.c
@@ -3999,14 +3999,17 @@ void ieee80211_if_setup(struct net_devic
}
-static void ieee80211_precalc_rates(struct ieee80211_hw *hw)
+static void ieee80211_precalc_modes(struct ieee80211_hw *hw,
+ struct ieee80211_local *local)
{
struct ieee80211_hw_modes *mode;
struct ieee80211_rate *rate;
int m, r;
+ local->hw_modes = 0;
for (m = 0; m < hw->num_modes; m++) {
mode = &hw->modes[m];
+ local->hw_modes |= 1 << mode->mode;
for (r = 0; r < mode->num_rates; r++) {
rate = &mode->rates[r];
rate->rate_inv = CHAN_UTIL_RATE_LCM / rate->rate;
@@ -4087,7 +4090,7 @@ struct net_device *ieee80211_alloc_hw(si
local->rate_ctrl_num_down = RATE_CONTROL_NUM_DOWN;
local->scan.in_scan = 0;
- local->hw_modes = (unsigned int) -1;
+ local->enabled_modes = (unsigned int) -1;
init_timer(&local->scan.timer); /* clear it out */
@@ -4257,7 +4260,7 @@ int ieee80211_update_hw(struct net_devic
!hw->modes->num_channels || !hw->modes->num_rates)
return -1;
- ieee80211_precalc_rates(hw);
+ ieee80211_precalc_modes(hw, local);
local->conf.phymode = hw->modes[0].mode;
local->curr_rates = hw->modes[0].rates;
local->num_curr_rates = hw->modes[0].num_rates;
diff --git a/net/d80211/ieee80211_i.h b/net/d80211/ieee80211_i.h
index ee0b399..595f6b1 100644
--- a/net/d80211/ieee80211_i.h
+++ b/net/d80211/ieee80211_i.h
@@ -409,7 +409,6 @@ #define IEEE80211_IRQSAFE_QUEUE_LIMIT 12
int scan_oper_antenna_max;
u8 scan_ssid[IEEE80211_MAX_SSID_LEN];
size_t scan_ssid_len;
- int scan_skip_11b;
struct list_head sta_bss_list;
struct ieee80211_sta_bss *sta_bss_hash[STA_HASH_SIZE];
spinlock_t sta_bss_lock;
@@ -500,7 +499,9 @@ #endif /* CONFIG_D80211_DEBUG_COUNTERS *
int wifi_wme_noack_test;
unsigned int wmm_acm; /* bit field of ACM bits (BIT(802.1D tag)) */
- unsigned int hw_modes; /* bitfield of allowed hardware modes;
+ unsigned int enabled_modes; /* bitfield of allowed modes;
+ * (1 << MODE_*) */
+ unsigned int hw_modes; /* bitfield of supported hardware modes;
* (1 << MODE_*) */
};
diff --git a/net/d80211/ieee80211_ioctl.c b/net/d80211/ieee80211_ioctl.c
index 5d31a8f..04df0a9 100644
--- a/net/d80211/ieee80211_ioctl.c
+++ b/net/d80211/ieee80211_ioctl.c
@@ -1699,7 +1699,7 @@ int ieee80211_ioctl_siwfreq(struct net_d
if (chan->flag & IEEE80211_CHAN_W_SCAN &&
((freq->e == 0 && chan->chan == freq->m) ||
(freq->e > 0 && nfreq == chan->freq)) &&
- (local->hw_modes & (1 << mode->mode))) {
+ (local->enabled_modes & (1 << mode->mode))) {
/* Use next_mode as the mode preference to
* resolve non-unique channel numbers. */
if (set && mode->mode != local->next_mode)
@@ -2447,7 +2447,7 @@ static int ieee80211_ioctl_prism2_param(
break;
case PRISM2_PARAM_HW_MODES:
- local->hw_modes = value;
+ local->enabled_modes = value;
break;
case PRISM2_PARAM_CREATE_IBSS:
@@ -2620,7 +2620,7 @@ static int ieee80211_ioctl_get_prism2_pa
break;
case PRISM2_PARAM_HW_MODES:
- *param = local->hw_modes;
+ *param = local->enabled_modes;
break;
case PRISM2_PARAM_CREATE_IBSS:
diff --git a/net/d80211/ieee80211_sta.c b/net/d80211/ieee80211_sta.c
index 2720f1d..af58013 100644
--- a/net/d80211/ieee80211_sta.c
+++ b/net/d80211/ieee80211_sta.c
@@ -2462,13 +2462,13 @@ static void ieee80211_sta_scan_timer(uns
}
return;
}
- skip = !(local->hw_modes & (1 << mode->mode));
+ skip = !(local->enabled_modes & (1 << mode->mode));
chan = &mode->channels[local->scan_channel_idx];
if (!(chan->flag & IEEE80211_CHAN_W_SCAN) ||
(sdata->type == IEEE80211_IF_TYPE_IBSS &&
!(chan->flag & IEEE80211_CHAN_W_IBSS)) ||
- (local->hw_modes & (1 << MODE_IEEE80211G) &&
- mode->mode == MODE_IEEE80211B && local->scan_skip_11b))
+ (local->hw_modes & local->enabled_modes &
+ (1 << MODE_IEEE80211G) && mode->mode == MODE_IEEE80211B))
skip = 1;
if (!skip) {
@@ -2566,7 +2566,6 @@ int ieee80211_sta_req_scan(struct net_de
memcpy(local->scan_ssid, ssid, ssid_len);
} else
local->scan_ssid_len = 0;
- local->scan_skip_11b = 1; /* FIX: clear this is 11g is not supported */
local->scan_state = SCAN_SET_CHANNEL;
local->scan_hw_mode_idx = 0;
local->scan_channel_idx = 0;
@@ -2592,7 +2591,7 @@ ieee80211_sta_scan_result(struct net_dev
bss->last_update + IEEE80211_SCAN_RESULT_EXPIRE))
return current_ev;
- if (!(local->hw_modes & (1 << bss->hw_mode)))
+ if (!(local->enabled_modes & (1 << bss->hw_mode)))
return current_ev;
if (local->scan_flags & IEEE80211_SCAN_WPA_ONLY &&
^ permalink raw reply related
* Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
From: Patrick McHardy @ 2006-05-15 18:41 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev
In-Reply-To: <Pine.SOC.4.61.0605152028420.9077@math.ut.ee>
Meelis Roos wrote:
>>> Iptables seems to be broken on ppc for me. Kernel 2.6.17-rc3 (currently
>>> compiling rc4+git). 32-bit ppc, ARCH=ppc with PReP target. Iptables
>>> userland binary is from the latest Debian unstable (1.3.3-2).
>>>
>>> The symptoms: iptables usually just tells Invalid Argument on any
>>> modification attempt. I'm trying to set up a simple one-rule NAT for
>>> test:
>>> iptables -t nat -A POSTROUTING -s 172.30.0.0/24 -j SNAT --to 10.0.0.1
>>> and it usually fails but has succeeded 2 times (I now have 2 rules of
>>> this kind and they seem to just wotk once set up). Trying to delete the
>>> second rule (either by replacing -A with -D or using just -D 2) gives
>>> the same error.
>>
>>
>>
>> This should already be fixed in -rc4.
>
>
> Unfortunately it was still there with yesterdays rc4+git.
I may have misinterpreted your report - are you running a 32bit or 64bit
kernel?
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Dan Williams @ 2006-05-15 19:12 UTC (permalink / raw)
To: Michael Buesch; +Cc: Jason Lunz, netdev
In-Reply-To: <200605151801.06379.mb@bu3sch.de>
On Mon, 2006-05-15 at 18:01 +0200, Michael Buesch wrote:
> On Monday 15 May 2006 17:27, you wrote:
> > mwallis@serialmonkey.com said:
> > > Some people are saying that instead of throwing and ACPI event we should be
> > > either use hotplug or internally just disable the radio and somehow inform
> > > the dscape stack that the radio has been disabled.
> > >
> > > What are peoples thoughts here, should we
> > >
> > > A. be handling this within our drivers and doing "what the user expects" and
> > > disabling the hardware radio, or
> >
> > On my HP laptop with bcm43xx wireless, the button disables the radio in
> > HARDWARE, and afaict the driver has no idea about it. The driver notices
> > that it's not connected and happily starts scanning again, unaware that
> > anything is wrong.
>
> There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> some "Radio is hardware-disabled" state. We currently don't use that flag
> correctly in the driver. Could you please assist me on testing if your switch
> actually toggles the bit?
> I think best place for this would be on irc.freenode.net #bcm-users
When those bits get set in the register, is the radio already disabled?
ie, for the bcm43xx chip, is it really force-disabled by the button, or
does the driver have some control?
Dan
^ permalink raw reply
* Re: ixp2000: handle enp2611s with two gigabit ports
From: Stephen Hemminger @ 2006-05-15 19:26 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: jgarzik, netdev
In-Reply-To: <20060426222411.GA9882@xi.wantstofly.org>
On Thu, 27 Apr 2006 00:24:11 +0200
Lennert Buytenhek <buytenh@wantstofly.org> wrote:
> The ixp2000 driver for the enp2611 was developed on a board with
> three gigabit ports, but some enp2611 models only have two ports
> (and only one onboard PM3386.) The current driver assumes there
> are always three ports and so it doesn't work on the two-port
> version of the board at all.
>
> This patch adds a bit of logic to the enp2611 driver to limit the
> number of ports to 2 if the second PM3386 isn't detected.
>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
This patch got mangled, that is probably why jeff didn't apply it before
he left. I had to fix it manually.
patching file drivers/net/ixp2000/enp2611.c
patch: **** malformed patch at line 106:
module_init(enp2611_init_module);
In this part...
@@ -236,8 +240,10 @@
del_timer_sync(&link_check_timer);
ixpdev_deinit();
- for (i = 0; i < 3; i++)
- free_netdev(nds[i]);
+ for (i = 0; i < 3; i++) {
+ if (nds[i] != NULL)
free_netdev(nds[i]);
+ }
}
module_init(enp2611_init_module);
^ permalink raw reply
* Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
From: Meelis Roos @ 2006-05-15 19:28 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <4468CB51.4060707@trash.net>
>>> This should already be fixed in -rc4.
>>
>> Unfortunately it was still there with yesterdays rc4+git.
>
> I may have misinterpreted your report - are you running a 32bit or 64bit
> kernel?
32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP
subarch, only buildable from the old ARCH=ppc code (not yet migrated to
ARCH=powerpc).
--
Meelis Roos (mroos@linux.ee)
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Michael Buesch @ 2006-05-15 19:32 UTC (permalink / raw)
To: Dan Williams, Jason Lunz, netdev
In-Reply-To: <1147720370.3067.14.camel@localhost.localdomain>
On Monday 15 May 2006 21:12, you wrote:
> > There are registers on the bcm43xx chip (0x158 and 0x49A) that indicate
> > some "Radio is hardware-disabled" state. We currently don't use that flag
> > correctly in the driver. Could you please assist me on testing if your switch
> > actually toggles the bit?
> > I think best place for this would be on irc.freenode.net #bcm-users
>
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?
Hm, actually, We don't know what the bit means. Could be some
completely different meaning. That is what I am trying to find
out. But it seems to have something to do with the power control
of the chip.
^ permalink raw reply
* Re: iptables broken on ppc (ptrace too?) (2.6.17-rc3)
From: Patrick McHardy @ 2006-05-15 19:36 UTC (permalink / raw)
To: Meelis Roos; +Cc: netdev
In-Reply-To: <Pine.SOC.4.61.0605152227290.8543@math.ut.ee>
Meelis Roos wrote:
>>>> This should already be fixed in -rc4.
>>>
>>>
>>> Unfortunately it was still there with yesterdays rc4+git.
>>
>>
>> I may have misinterpreted your report - are you running a 32bit or 64bit
>> kernel?
>
>
> 32-bit kernel, this is a Motorola Powerstack II macine with 604e. PReP
> subarch, only buildable from the old ARCH=ppc code (not yet migrated to
> ARCH=powerpc).
Ah OK, I thought it was related to the new compat code, but that isn't
the case. Your trace doesn't give much clues, except that it shows that
iptables dies with a SIGSEGV, which might be a bug in userspace or in
the kernel. Which was the last kernel that worked for you, and can you
try that version again to rule out userspace bugs?
^ permalink raw reply
* Re: Hardware button support for Wireless cards
From: Jason Lunz @ 2006-05-15 19:46 UTC (permalink / raw)
To: Dan Williams; +Cc: Michael Buesch, netdev
In-Reply-To: <1147720370.3067.14.camel@localhost.localdomain>
On Mon, May 15, 2006 at 03:12:50PM -0400, Dan Williams wrote:
> When those bits get set in the register, is the radio already disabled?
> ie, for the bcm43xx chip, is it really force-disabled by the button, or
> does the driver have some control?
I assume it disables the radio without any help from the driver, because
it definitely turns off my radio, but the bcm43xx driver i'm using (in
2.6.17-rc4) currently doesn't pay any attention to those registers
afaik.
Jason
^ permalink raw reply
* Re: Patches from Marcin Juszkiewicz
From: John W. Linville @ 2006-05-15 20:06 UTC (permalink / raw)
To: Pavel Roskin; +Cc: netdev, David Gibson, Marcin Juszkiewicz
In-Reply-To: <1147466610.8478.41.camel@dv>
On Fri, May 12, 2006 at 04:43:30PM -0400, Pavel Roskin wrote:
> As a co-maintainer of Orinoco driver, I'd like to ask the netdev team
> not to apply any patch from Marcin Juszkiewicz touching the Orinoco
> driver without my or David's explicit approval.
I plan to honor this request. Are there any objections?
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox