On Fri, 2006-09-01 at 18:28 +1200, Paul Collins wrote:
> That said I do wonder if bcm43xx currently supports anything except
> PCI (and PCI-e, I guess) devices.
No, I don't think it does, but I have some clue as to how it might work
so we could spec it. Just didn't think such a device would show
"David Reimer" <[EMAIL PROTECTED]> writes:
> I've recompiled my kernel with both "CONFIG_PCCARD_NONSTATIC=y &
> CONFIG_YENTA=y".
>
> I've alsocontacted my hardware provider. They've informed me that they card
> is 16-bit. Kind of a suprise to me. Any suggestiion on what I need to get a
> 16-bit
On Thu, 2006-08-31 at 21:51 +0200, Martin Langer wrote:
> If you change endianess it will be harder to read the CC value! And that
> value is really at that position. So I think we already chose the best
> endianess.
Yeah, sorry for the confusion. I was completely confused because I
thought I h
I've recompiled my kernel with both "CONFIG_PCCARD_NONSTATIC=y &
CONFIG_YENTA=y".
I've alsocontacted my hardware provider. They've informed me that they card
is 16-bit. Kind of a suprise to me. Any suggestiion on what I need to get a
16-bit pcmcia card to be reported by 'lspci', or is there som
On Wed, Aug 30, 2006 at 10:52:43AM +0200, Martin Langer wrote:
> On Wed, Aug 30, 2006 at 09:25:27AM +0200, Johannes Berg wrote:
> > On Tue, 2006-08-29 at 19:23 +0200, Martin Langer wrote:
> >
> > > AA BC CD DD EE EE FF FG
> >
> > And isn't this the little endian format? Maybe it's easier to unde
After modifying my firmware I have to correct the meaning of B and
G of lesson #2 a little bit...
Last time we read our 64 bit segments in this way
AA BC CD DD EE EE FF FG
AA value (high)
CC value (low)
DDD shm offset
0, not used
FFF command
But B and G are mask swi
This patch prints microcode revision, patchlevel, date and time to
KERN_INFO. Also, version 4.xx microcodes (rev>0x128) will be rejected
by the driver, because they still do not work.
Signed-off-by: Martin Langer <[EMAIL PROTECTED]>
--- drivers/net/wireless/bcm43xx/bcm43xx_main.c.ORIGINAL
John,
As discussed earlier, here is the wireless-2.6 patch for WE-21 in
bcm43xx-softmac. The core patch
for the SSID length, which I believe is non-controversial, must be applied
first.
Larry
--
Patch to make bcm43xx-softmac be compatible w
On Thu, Aug 31, 2006 at 08:22:22AM -0500, Larry Finger wrote:
> John, have you merged, or do you plan to merge, "[PATCH 2.6.18] WE-21 support
> (core API)" into
> wireless-2.6?
I guess that is still up for discussion. It looks like at least part
of it is desirable, but maybe not other parts.
P
Michael Buesch wrote:
> On Thursday 31 August 2006 02:57, Larry Finger wrote:
>>
>> +#if WIRELESS_EXT > 20
>> +#define IW_ESSID_FIX0
>> +#else
>> +#define IW_ESSID_FIX1
>> +#endif
>
> Eh, was this useless #if in the original patch I signed-off, too?
> Because I want to revert my si
On Thursday 31 August 2006 02:25, Andrew Fuller wrote:
> On 8/26/06, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > Well, it _should_ be solved for cards that support >1G
> > of memory. Latest devicescape based driver has support
> > for the Address Extension bits and the 64bit DMA engine.
> >
> > T
On Thursday 31 August 2006 02:57, Larry Finger wrote:
> John,
>
> Please apply Jean's patch to wireless-2.6. It should apply cleanly to the
> version you pushed earlier
> today (8/30). I have compiled and tested. For complete operation with WE-21,
> it also needs the patch
> entitled [PATCH 2.6.
Am Donnerstag 31 August 2006 06:09 schrieb David Reimer:
> CONFIG_PCCARD_NONSTATIC=m
"modprobe yenta_socket" for this case. As I almost always need it, I have it
set to y (and also CONFIG_YENTA=y).
HS
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berl
On Wed, 2006-08-30 at 20:25 -0400, Andrew Fuller wrote:
> bcm43xx_d80211: 32-bit DMA initialized
>
> So it didn't seem to be using the 64bit DMA. Does it automatically
> load 32/64 that it needs/supports?
Not all cards support 64-bit DMA, in fact I think only PCI-E ones
possibly do but you'd ha
On Wed, 2006-08-30 at 19:51 +0200, Hendrik Sattler wrote:
> If the vendor of you card has set itself as primary vendor instead of
> secondary vendor
This is not possible with the SPROM format of the card, the vendor ID is
hardcoded, only product/subvendor/subproduct are changeable.
johannes
___
15 matches
Mail list logo
