On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
> > On 1st sight, logs look fine:
> >
> > [21:52:52] <lautriv> [ ? ?6.050967] ieee80211 phy0: 88w8361p v4,
> > 00173f3bdde3, STA firmware 2.1.4.25
> >
> > But WLAN connection is not that fast and stable as lautriv reports
> > (several abnormalities were observed).
> >
> > I requested a tarball which includes:
> > * dmesg (Linux-3.3.3)
> > * e_n_a (/etc/network/interfaces)
> > * ifconfig output
> > * iwconfig output
> > * iw_phy output
> > * ps_axu (WPA) output
> >
> > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > next days (UTC+2: German/Swiss local-time).
> > Just ping him.
> >
> > Hope you have fun, together!
> >
> > - Sedat -
>
> A new tarball from lautriv with same outputs as before, but now tested
> with Linux-3.4-rc4.
The output looks good enough for me to ACK adding the PCI ID.
Can the firmware being used here be submitted to the linux-firmware
git tree?
On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
<[email protected]> wrote:
> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
>
>> > On 1st sight, logs look fine:
>> >
>> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
>> > 00173f3bdde3, STA firmware 2.1.4.25
>> >
>> > But WLAN connection is not that fast and stable as lautriv reports
>> > (several abnormalities were observed).
>> >
>> > I requested a tarball which includes:
>> > * dmesg (Linux-3.3.3)
>> > * e_n_a (/etc/network/interfaces)
>> > * ifconfig output
>> > * iwconfig output
>> > * iw_phy output
>> > * ps_axu (WPA) output
>> >
>> > lautriv will be so kind to be around on #linux-wireless/Freenode the
>> > next days (UTC+2: German/Swiss local-time).
>> > Just ping him.
>> >
>> > Hope you have fun, together!
>> >
>> > - Sedat -
>>
>> A new tarball from lautriv with same outputs as before, but now tested
>> with Linux-3.4-rc4.
[ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ]
> The output looks good enough for me to ACK adding the PCI ID.
>
> Can the firmware being used here be submitted to the linux-firmware
> git tree?
I can't say much about the firmware [1] inclusion or the procedure of
it into linux-firmware [2].
Maybe, Ben can explain the procedure and what has to be considered
before inclusion in linux-firmware.
The original firmware and helper images were extracted from a Netgear
Windows driver [1].
>From what I read in the OpenWrt forum posting [3]: You wanted to care
for inclusion:
"Firmware isn't included in the kernel tree anymore, there's the
linux-firmware git tree for that these days. I will contact some
people at Marvell to ask whether 8361P firmware can be included
there."
Some more concerns...
Dunno, if [4] is really correct and how to use one and same device-id
for 8363 ***and*** 8361P:
...
{ PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, },
...
Curious about a statement from hauke...
Adding the device-id in case of 8361P is not enough (see attached patch)
I am looking forward to having support for 8361P soon.
- Sedat -
P.S.: I have re-added Readme and patch as there are new CCs.
[1] ftp://downloads.netgear.com/files/wn311t_4_2_setup.exe
[2] http://git.kernel.org/?p=linux/kernel/git/firmware/linux-firmware.git;a=summary
[3] https://forum.openwrt.org/viewtopic.php?pid=110039#p110039
[4] https://dev.openwrt.org/changeset/21167
On Tue, May 01, 2012 at 03:54:49PM +0200, Sedat Dilek wrote:
> Some more concerns...
> Dunno, if [4] is really correct and how to use one and same device-id
> for 8363 ***and*** 8361P:
> ...
> { PCI_VDEVICE(MARVELL, 0x2a02), .driver_data = MWL8363, },
No, you'll have to add a MWL8361P to the enum, and add a
mwl8k_device_info table entry for that, and then add the PCI ID
table entry with the MWL8361P identifier.
On 05/01/2012 09:54 AM, Sedat Dilek wrote:
> --- a/drivers/net/wireless/mwl8k.c
> +++ b/drivers/net/wireless/mwl8k.c
> @@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
> }
>
> enum {
> + MWL8361P = 0,
> MWL8363 = 0,
> MWL8687,
> MWL8366,
I'm not an expert, but isn't this giving both 8361P and 8363 the same values in the enum?
Is that intended?
Pat Erley
On Tue, May 01, 2012 at 09:12:25PM -0400, Pat Erley wrote:
> >--- a/drivers/net/wireless/mwl8k.c
> >+++ b/drivers/net/wireless/mwl8k.c
> >@@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
> > }
> >
> > enum {
> >+ MWL8361P = 0,
> > MWL8363 = 0,
> > MWL8687,
> > MWL8366,
>
> I'm not an expert, but isn't this giving both 8361P and 8363 the
> same values in the enum?
Yeah, this is broken.
On 05/01/2012 03:54 PM, Sedat Dilek wrote:
> On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
> <[email protected]> wrote:
>> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
>>
>>>> On 1st sight, logs look fine:
>>>>
>>>> [21:52:52]<lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
>>>> 00173f3bdde3, STA firmware 2.1.4.25
>>>>
>>>> But WLAN connection is not that fast and stable as lautriv reports
>>>> (several abnormalities were observed).
>>>>
>>>> I requested a tarball which includes:
>>>> * dmesg (Linux-3.3.3)
>>>> * e_n_a (/etc/network/interfaces)
>>>> * ifconfig output
>>>> * iwconfig output
>>>> * iw_phy output
>>>> * ps_axu (WPA) output
>>>>
>>>> lautriv will be so kind to be around on #linux-wireless/Freenode the
>>>> next days (UTC+2: German/Swiss local-time).
>>>> Just ping him.
>>>>
>>>> Hope you have fun, together!
>>>>
>>>> - Sedat -
>>>
>>> A new tarball from lautriv with same outputs as before, but now tested
>>> with Linux-3.4-rc4.
>
> [ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ]
>
>> The output looks good enough for me to ACK adding the PCI ID.
>>
>> Can the firmware being used here be submitted to the linux-firmware
>> git tree?
>
> I can't say much about the firmware [1] inclusion or the procedure of
> it into linux-firmware [2].
> Maybe, Ben can explain the procedure and what has to be considered
> before inclusion in linux-firmware.
> The original firmware and helper images were extracted from a Netgear
> Windows driver [1].
>
> From what I read in the OpenWrt forum posting [3]: You wanted to care
> for inclusion:
>
> "Firmware isn't included in the kernel tree anymore, there's the
> linux-firmware git tree for that these days. I will contact some
> people at Marvell to ask whether 8361P firmware can be included
> there."
Basically, all firmware in linux-firmware repository should be
accompanied with license information. Also you are signing off the patch
to add the firmware to the repository so you are bound to the
Developer's Certificate of Origin 1.1 in [1]. Having the firmware
extracted from a windows driver does not fall under that statement,
unless Marvell is ok with its redistribution. Recently a patch was
submitted for a README in the linux-firmware repository about the
process. It must be a binary patch. Easiest way is to use 'git
format-patch -B'.
Gr. AvS
[1] http://lxr.linux.no/linux+v3.3.4/Documentation/SubmittingPatches
[2] https://lkml.org/lkml/2012/4/21/177
On Wed, May 2, 2012 at 4:38 AM, Lennert Buytenhek
<[email protected]> wrote:
> On Tue, May 01, 2012 at 09:12:25PM -0400, Pat Erley wrote:
>
>> >--- a/drivers/net/wireless/mwl8k.c
>> >+++ b/drivers/net/wireless/mwl8k.c
>> >@@ -5225,6 +5225,7 @@ static void mwl8k_finalize_join_worker(struct work_struct *work)
>> > }
>> >
>> > enum {
>> >+ MWL8361P = 0,
>> > MWL8363 = 0,
>> > MWL8687,
>> > MWL8366,
>>
>> I'm not an expert, but isn't this giving both 8361P and 8363 the
>> same values in the enum?
>
> Yeah, this is broken.
Before this email, Helmut pointed me to the enum thingie in a private query.
As I was busy with OverlayFS the last days, I couldn't give that
information back.
So, this should be:
...
enum {
MWL8361P = 0,
MWL8363,
MWL8687,
MWL8366,
...
Shall I cook up a new patch with a proper history and documented
origin (original patch is from OpenWrt, I refreshed it against
upstream)?
...add some Tested-by (Helmut, Jim)...
...send that to linux-wireless ML for a review?
- Sedat -
On Tue, 2012-05-01 at 15:54 +0200, Sedat Dilek wrote:
> On Tue, May 1, 2012 at 2:51 PM, Lennert Buytenhek
> <[email protected]> wrote:
> > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
> >
> >> > On 1st sight, logs look fine:
> >> >
> >> > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> >> > 00173f3bdde3, STA firmware 2.1.4.25
> >> >
> >> > But WLAN connection is not that fast and stable as lautriv reports
> >> > (several abnormalities were observed).
> >> >
> >> > I requested a tarball which includes:
> >> > * dmesg (Linux-3.3.3)
> >> > * e_n_a (/etc/network/interfaces)
> >> > * ifconfig output
> >> > * iwconfig output
> >> > * iw_phy output
> >> > * ps_axu (WPA) output
> >> >
> >> > lautriv will be so kind to be around on #linux-wireless/Freenode the
> >> > next days (UTC+2: German/Swiss local-time).
> >> > Just ping him.
> >> >
> >> > Hope you have fun, together!
> >> >
> >> > - Sedat -
> >>
> >> A new tarball from lautriv with same outputs as before, but now tested
> >> with Linux-3.4-rc4.
>
> [ CC hauke (OpenWrt) and Ben Hutchings (linux-firmware maintainer) ]
>
> > The output looks good enough for me to ACK adding the PCI ID.
> >
> > Can the firmware being used here be submitted to the linux-firmware
> > git tree?
>
> I can't say much about the firmware [1] inclusion or the procedure of
> it into linux-firmware [2].
> Maybe, Ben can explain the procedure and what has to be considered
> before inclusion in linux-firmware.
> The original firmware and helper images were extracted from a Netgear
> Windows driver [1].
[...]
Even assuming that the original driver binary is freely redistributable,
it's not at all clear that these extracted blobs would be.
If there's some difficulty in getting a sensible licence for the
firmware, you can consider providing a tool to do this extraction, as
has been done for some other drivers whose vendors don't provide the
firmware blobs alone. However, as yet, linux-firmware doesn't include
any such extraction tools and I would need to discuss such an addition
with David (and maybe other distribution maintainers). Hopefully that
won't be necessary, though.
Ben.
--
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote:
> On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
>
> > > On 1st sight, logs look fine:
> > >
> > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> > > 00173f3bdde3, STA firmware 2.1.4.25
> > >
> > > But WLAN connection is not that fast and stable as lautriv reports
> > > (several abnormalities were observed).
> > >
> > > I requested a tarball which includes:
> > > * dmesg (Linux-3.3.3)
> > > * e_n_a (/etc/network/interfaces)
> > > * ifconfig output
> > > * iwconfig output
> > > * iw_phy output
> > > * ps_axu (WPA) output
> > >
> > > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > > next days (UTC+2: German/Swiss local-time).
> > > Just ping him.
> > >
> > > Hope you have fun, together!
> > >
> > > - Sedat -
> >
> > A new tarball from lautriv with same outputs as before, but now tested
> > with Linux-3.4-rc4.
>
> The output looks good enough for me to ACK adding the PCI ID.
>
> Can the firmware being used here be submitted to the linux-firmware
> git tree?
So Marvell sent John a driver for TopDog a long time ago, which he put
up on kernel.org. That driver was reworked by Louis and put up in a git
tree, but both were lost to the kernel.org hack. I have git backups of
both git trees. I put Louis' cleanup here:
http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2
That driver (mrvl_cb82) has the following PCI IDs:
static const struct pci_device_id mwl_id_tbl[] __devinitdata = {
{ PCI_VDEVICE(MARVELL, 0x2a02), 0 },
{ PCI_VDEVICE(MARVELL, 0x2a03), 1 },
{ PCI_VDEVICE(MARVELL, 0x2a06), 2 },
{ PCI_VDEVICE(MARVELL, 0x2a07), 3 },
{ PCI_VDEVICE(MARVELL, 0x2a04), 4 },
{ PCI_VDEVICE(MARVELL, 0x2a08), 5 },
{ PCI_VDEVICE(MARVELL, 0x2a0a), 6 },
{ PCI_VDEVICE(MARVELL, 0x2a0b), 7 },
{ PCI_VDEVICE(MARVELL, 0x2a0c), 8 },
{ 0 }
};
and supposedly works for CB82 + CB85. The firmware helper for CB82
looks pretty close to the mwl8k one.
The firmware API exposed by mrvl_cb82 looks very close to mwl8k
actually. I only checked the HostCmd bits, not the structures, so I
would expect a few differences. There are some commands that mwl8k
exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the
drivers actually use those commands.
Hope this helps.
Dan
On Mon, 2012-05-07 at 11:09 -0500, Dan Williams wrote:
> On Tue, 2012-05-01 at 14:51 +0200, Lennert Buytenhek wrote:
> > On Sun, Apr 29, 2012 at 12:25:21AM +0200, Sedat Dilek wrote:
> >
> > > > On 1st sight, logs look fine:
> > > >
> > > > [21:52:52] <lautriv> [ 6.050967] ieee80211 phy0: 88w8361p v4,
> > > > 00173f3bdde3, STA firmware 2.1.4.25
> > > >
> > > > But WLAN connection is not that fast and stable as lautriv reports
> > > > (several abnormalities were observed).
> > > >
> > > > I requested a tarball which includes:
> > > > * dmesg (Linux-3.3.3)
> > > > * e_n_a (/etc/network/interfaces)
> > > > * ifconfig output
> > > > * iwconfig output
> > > > * iw_phy output
> > > > * ps_axu (WPA) output
> > > >
> > > > lautriv will be so kind to be around on #linux-wireless/Freenode the
> > > > next days (UTC+2: German/Swiss local-time).
> > > > Just ping him.
> > > >
> > > > Hope you have fun, together!
> > > >
> > > > - Sedat -
> > >
> > > A new tarball from lautriv with same outputs as before, but now tested
> > > with Linux-3.4-rc4.
> >
> > The output looks good enough for me to ACK adding the PCI ID.
> >
> > Can the firmware being used here be submitted to the linux-firmware
> > git tree?
>
> So Marvell sent John a driver for TopDog a long time ago, which he put
> up on kernel.org. That driver was reworked by Louis and put up in a git
> tree, but both were lost to the kernel.org hack. I have git backups of
> both git trees. I put Louis' cleanup here:
>
> http://people.redhat.com/dcbw/mrvl_cb82.tar.bz2
>
> That driver (mrvl_cb82) has the following PCI IDs:
>
> static const struct pci_device_id mwl_id_tbl[] __devinitdata = {
> { PCI_VDEVICE(MARVELL, 0x2a02), 0 },
> { PCI_VDEVICE(MARVELL, 0x2a03), 1 },
> { PCI_VDEVICE(MARVELL, 0x2a06), 2 },
> { PCI_VDEVICE(MARVELL, 0x2a07), 3 },
> { PCI_VDEVICE(MARVELL, 0x2a04), 4 },
> { PCI_VDEVICE(MARVELL, 0x2a08), 5 },
> { PCI_VDEVICE(MARVELL, 0x2a0a), 6 },
> { PCI_VDEVICE(MARVELL, 0x2a0b), 7 },
> { PCI_VDEVICE(MARVELL, 0x2a0c), 8 },
> { 0 }
> };
>
> and supposedly works for CB82 + CB85. The firmware helper for CB82
> looks pretty close to the mwl8k one.
>
> The firmware API exposed by mrvl_cb82 looks very close to mwl8k
> actually. I only checked the HostCmd bits, not the structures, so I
> would expect a few differences. There are some commands that mwl8k
> exposes that mrvl_cb82 does not and vice versa, but I'm not sure if the
> drivers actually use those commands.
As for AP mode, the Marvell Extranet does have AP-mode drivers for the
8361 and 8363, but the zipfiles are password-protected and I have no
idea what license they are supposed to be under due to that. Thus I
cannot get the AP mode firmware for those either to submit to
linux-firmware.
Dan
Hi,
Let me see if the topdog firmware that FreeBSD ships with supports hostap mode.
I'm having aggregation issues but I think that's driver side, not firmware side.
Adrian
On 05/07/2012 08:26 PM, Adrian Chadd wrote:
> Hi,
>
> Let me see if the topdog firmware that FreeBSD ships with supports hostap mode.
>
> I'm having aggregation issues but I think that's driver side, not firmware side.
>
>
>
> Adrian
>
i didn't change anything since the manual addition
of the patch into 3.4-rc and it looks like only the reported
speed is worse, taking the card up with wpa_sup gives me
enought speed to transfer audiovisual content without
loss or stutter.
( card is on a mythfrontend using DVD-quality streams ).
may be comfortable to have certain commands working
or using the AP capabilities but at least the gerneric usage
is given.
Helmut