From corbet at lwn.net  Thu Jun  1 09:11:13 2017
From: corbet at lwn.net (Jonathan Corbet)
Date: Thu, 1 Jun 2017 10:11:13 -0600
Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in
 b43legacy_attr_interfmode_store
In-Reply-To: <592F6843.9000204@163.com>
References: <1496226547-5921-1-git-send-email-baijiaju1990@163.com>
 <85905124-7167-aeb0-8aff-4ceec09e9542@lwfinger.net>
 <592F6843.9000204@163.com>
Message-ID: <20170601101113.6dd30d6d@lwn.net>

On Thu, 01 Jun 2017 09:05:07 +0800
Jia-Ju Bai <baijiaju1990 at 163.com> wrote:

> I admit my patches are not well tested, and they may not well fix the bugs.
> I am looking forward to opinions and suggestions :)

May I politely suggest that sending out untested locking changes is a
dangerous thing to do?  You really should not be changing the locking in a
piece of kernel code without understanding very well what the lock is
protecting and being able to say why your changes are safe.  Without that,
the risk of introducing subtle bugs is very high.

It looks like you have written a useful tool that could help us to make
the kernel more robust.  If you are interested in my suggestion, I would
recommend that you post the sleep-in-atomic scenarios that you are
finding, but refrain from "fixing" them in any case where you cannot offer
a strong explanation of why your fix is correct.

Thanks for working to find bugs in the kernel!

jon


From Larry.Finger at lwfinger.net  Thu Jun  1 10:43:41 2017
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Thu, 1 Jun 2017 12:43:41 -0500
Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in
 b43legacy_attr_interfmode_store
In-Reply-To: <20170601101113.6dd30d6d@lwn.net>
References: <1496226547-5921-1-git-send-email-baijiaju1990@163.com>
 <85905124-7167-aeb0-8aff-4ceec09e9542@lwfinger.net>
 <592F6843.9000204@163.com> <20170601101113.6dd30d6d@lwn.net>
Message-ID: <ff1dd7ad-e8d5-bb3e-9a38-3eefcc8e3b23@lwfinger.net>

On 06/01/2017 11:11 AM, Jonathan Corbet wrote:
> On Thu, 01 Jun 2017 09:05:07 +0800
> Jia-Ju Bai <baijiaju1990 at 163.com> wrote:
> 
>> I admit my patches are not well tested, and they may not well fix the bugs.
>> I am looking forward to opinions and suggestions :)
> 
> May I politely suggest that sending out untested locking changes is a
> dangerous thing to do?  You really should not be changing the locking in a
> piece of kernel code without understanding very well what the lock is
> protecting and being able to say why your changes are safe.  Without that,
> the risk of introducing subtle bugs is very high.
> 
> It looks like you have written a useful tool that could help us to make
> the kernel more robust.  If you are interested in my suggestion, I would
> recommend that you post the sleep-in-atomic scenarios that you are
> finding, but refrain from "fixing" them in any case where you cannot offer
> a strong explanation of why your fix is correct.
> 
> Thanks for working to find bugs in the kernel!

I agree with the suggestion above. Locking changes should only be done in 
conjunction with testing by someone that actually has the hardware.

Larry




From lkp at intel.com  Thu Jun  1 16:24:29 2017
From: lkp at intel.com (kbuild test robot)
Date: Fri, 2 Jun 2017 07:24:29 +0800
Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in
 b43legacy_attr_interfmode_store
In-Reply-To: <1496226547-5921-1-git-send-email-baijiaju1990@163.com>
Message-ID: <201706020741.xCELNDWA%fengguang.wu@intel.com>

Hi Jia-Ju,

[auto build test WARNING on wireless-drivers-next/master]
[also build test WARNING on v4.12-rc3 next-20170601]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Jia-Ju-Bai/b43legacy-Fix-a-sleep-in-atomic-bug-in-b43legacy_attr_interfmode_store/20170531-192639
base:   https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master
config: x86_64-randconfig-a0-06020536 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/net/wireless/broadcom/b43legacy/sysfs.c: In function 'b43legacy_attr_interfmode_store':
>> drivers/net/wireless/broadcom/b43legacy/sysfs.c:114: warning: unused variable 'flags'

vim +/flags +114 drivers/net/wireless/broadcom/b43legacy/sysfs.c

75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25   98  				 " Mitigation)\n");
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25   99  		break;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  100  	default:
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  101  		B43legacy_WARN_ON(1);
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  102  	}
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  103  
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  104  	mutex_unlock(&wldev->wl->mutex);
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  105  
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  106  	return count;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  107  }
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  108  
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  109  static ssize_t b43legacy_attr_interfmode_store(struct device *dev,
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  110  					       struct device_attribute *attr,
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  111  					       const char *buf, size_t count)
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  112  {
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  113  	struct b43legacy_wldev *wldev = dev_to_b43legacy_wldev(dev);
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25 @114  	unsigned long flags;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  115  	int err;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  116  	int mode;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  117  
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  118  	if (!capable(CAP_NET_ADMIN))
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  119  		return -EPERM;
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  120  
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  121  	mode = get_integer(buf, count);
75388acd drivers/net/wireless/b43legacy/sysfs.c Larry Finger 2007-09-25  122  	switch (mode) {

:::::: The code at line 114 was first introduced by commit
:::::: 75388acd0cd827dc1498043daa7d1c760902cd67 [B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices

:::::: TO: Larry Finger <Larry.Finger at lwfinger.net>
:::::: CC: David S. Miller <davem at sunset.davemloft.net>

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 27408 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20170602/4eb5535f/attachment-0001.gz>

From baijiaju1990 at 163.com  Thu Jun  1 18:18:14 2017
From: baijiaju1990 at 163.com (Jia-Ju Bai)
Date: Fri, 02 Jun 2017 09:18:14 +0800
Subject: [PATCH] b43legacy: Fix a sleep-in-atomic bug in
 b43legacy_attr_interfmode_store
In-Reply-To: <20170601101113.6dd30d6d@lwn.net>
References: <1496226547-5921-1-git-send-email-baijiaju1990@163.com>
 <85905124-7167-aeb0-8aff-4ceec09e9542@lwfinger.net>
 <592F6843.9000204@163.com> <20170601101113.6dd30d6d@lwn.net>
Message-ID: <5930BCD6.9010306@163.com>

On 06/02/2017 12:11 AM, Jonathan Corbet wrote:
> On Thu, 01 Jun 2017 09:05:07 +0800
> Jia-Ju Bai<baijiaju1990 at 163.com>  wrote:
>
>> I admit my patches are not well tested, and they may not well fix the bugs.
>> I am looking forward to opinions and suggestions :)
> May I politely suggest that sending out untested locking changes is a
> dangerous thing to do?  You really should not be changing the locking in a
> piece of kernel code without understanding very well what the lock is
> protecting and being able to say why your changes are safe.  Without that,
> the risk of introducing subtle bugs is very high.
>
> It looks like you have written a useful tool that could help us to make
> the kernel more robust.  If you are interested in my suggestion, I would
> recommend that you post the sleep-in-atomic scenarios that you are
> finding, but refrain from "fixing" them in any case where you cannot offer
> a strong explanation of why your fix is correct.
>
> Thanks for working to find bugs in the kernel!
>
> jon
Hi,

Thanks for your good and helpful advice. I am sorry for my improper patches.
I will only report bugs instead of sending improper patches when I have 
no good solution of fixing the bugs.

Thanks,
Jia-Ju Bai



From jprvita at endlessm.com  Tue Jun  6 18:02:22 2017
From: jprvita at endlessm.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?=)
Date: Tue, 6 Jun 2017 18:02:22 -0700
Subject: Using b43-fwcutter on Windows drivers
Message-ID: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>

Hello b43 developers,

Is it possible to use b43-fwcutter to extract firmware from Windows
drivers? The manpage says "Currently b43-fwcutter supports Apple MacOS
X, Microsoft Windows and Linux drivers, but keep in mind that
b43-fwcutter doesn't support all driver versions.", but looking at
fwcutter_list.h I don't see entries for the windows drivers. Are
offsets for windows drivers available somewhere?

Thanks,

......................................................................................
Jo?o Paulo Rechi Vita  |  +1.415.851.5778  |  Endless


From Larry.Finger at lwfinger.net  Tue Jun  6 18:41:19 2017
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Tue, 6 Jun 2017 20:41:19 -0500
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
Message-ID: <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>

On 06/06/2017 08:02 PM, Jo?o Paulo Rechi Vita wrote:
> Hello b43 developers,
> 
> Is it possible to use b43-fwcutter to extract firmware from Windows
> drivers? The manpage says "Currently b43-fwcutter supports Apple MacOS
> X, Microsoft Windows and Linux drivers, but keep in mind that
> b43-fwcutter doesn't support all driver versions.", but looking at
> fwcutter_list.h I don't see entries for the windows drivers. Are
> offsets for windows drivers available somewhere?

The reason that you do not see any entries for Windows drivers is because those 
drivers are stripped such that we can get the offsets, but not the description 
for that particular firmware entry. One could go through each one and identify 
the correspondence with other firmware sources, but that would be very laborious 
and error prone. I have chosen not to try that approach.

What do you hope to gain from Windows firmware? Extracting firmware from the 
Linux drivers should yield better firmware if the two operating systems have 
different requirements.

Larry


From jprvita at endlessm.com  Wed Jun  7 17:08:32 2017
From: jprvita at endlessm.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?=)
Date: Wed, 7 Jun 2017 17:08:32 -0700
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
Message-ID: <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>

On Tue, Jun 6, 2017 at 6:41 PM, Larry Finger <Larry.Finger at lwfinger.net> wrote:
> On 06/06/2017 08:02 PM, Jo?o Paulo Rechi Vita wrote:
>>
>> Hello b43 developers,
>>
>> Is it possible to use b43-fwcutter to extract firmware from Windows
>> drivers? The manpage says "Currently b43-fwcutter supports Apple MacOS
>> X, Microsoft Windows and Linux drivers, but keep in mind that
>> b43-fwcutter doesn't support all driver versions.", but looking at
>> fwcutter_list.h I don't see entries for the windows drivers. Are
>> offsets for windows drivers available somewhere?
>
>
> The reason that you do not see any entries for Windows drivers is because
> those drivers are stripped such that we can get the offsets, but not the
> description for that particular firmware entry. One could go through each
> one and identify the correspondence with other firmware sources, but that
> would be very laborious and error prone. I have chosen not to try that
> approach.
>
> What do you hope to gain from Windows firmware? Extracting firmware from the
> Linux drivers should yield better firmware if the two operating systems have
> different requirements.
>

Thanks for your reply, Larry.

The idea is to help non-techy users on dual-boot installations, when
they have no other means to connect their Linux system to the
internet. On Endless we support a very specific Windows+Endless
dual-boot layout, so it is easy for us to find the Windows partition.
We want grab the Windows drivers and extract the firmware files from
them automatically when a compatible card is detected and the user is
offline.

I understand that there is some manual work involved on this, but are
there any pointers on how to get the offsets from the Windows drivers?
I could check if the extracted data matches anything we already know
from the wl firmware.

Also, you mention that firmware may be different due to different OS
requirements -- I expected the hw (thus, also the firmware) to behave
the same way despite which OS is running on the CPU. Maybe I'm being
naive here?

......................................................................................
Jo?o Paulo Rechi Vita  |  +1.415.851.5778  |  Endless


From Larry.Finger at lwfinger.net  Wed Jun  7 21:48:00 2017
From: Larry.Finger at lwfinger.net (Larry Finger)
Date: Wed, 7 Jun 2017 23:48:00 -0500
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
 <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
Message-ID: <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>

On 06/07/2017 07:08 PM, Jo?o Paulo Rechi Vita wrote:
> On Tue, Jun 6, 2017 at 6:41 PM, Larry Finger <Larry.Finger at lwfinger.net> wrote:
>> On 06/06/2017 08:02 PM, Jo?o Paulo Rechi Vita wrote:
>>>
>>> Hello b43 developers,
>>>
>>> Is it possible to use b43-fwcutter to extract firmware from Windows
>>> drivers? The manpage says "Currently b43-fwcutter supports Apple MacOS
>>> X, Microsoft Windows and Linux drivers, but keep in mind that
>>> b43-fwcutter doesn't support all driver versions.", but looking at
>>> fwcutter_list.h I don't see entries for the windows drivers. Are
>>> offsets for windows drivers available somewhere?
>>
>>
>> The reason that you do not see any entries for Windows drivers is because
>> those drivers are stripped such that we can get the offsets, but not the
>> description for that particular firmware entry. One could go through each
>> one and identify the correspondence with other firmware sources, but that
>> would be very laborious and error prone. I have chosen not to try that
>> approach.
>>
>> What do you hope to gain from Windows firmware? Extracting firmware from the
>> Linux drivers should yield better firmware if the two operating systems have
>> different requirements.
>>
> 
> Thanks for your reply, Larry.
> 
> The idea is to help non-techy users on dual-boot installations, when
> they have no other means to connect their Linux system to the
> internet. On Endless we support a very specific Windows+Endless
> dual-boot layout, so it is easy for us to find the Windows partition.
> We want grab the Windows drivers and extract the firmware files from
> them automatically when a compatible card is detected and the user is
> offline.
> 
> I understand that there is some manual work involved on this, but are
> there any pointers on how to get the offsets from the Windows drivers?
> I could check if the extracted data matches anything we already know
> from the wl firmware.
> 
> Also, you mention that firmware may be different due to different OS
> requirements -- I expected the hw (thus, also the firmware) to behave
> the same way despite which OS is running on the CPU. Maybe I'm being
> naive here?

In general, the firmware should be the same, but as I have not seen any 
specifics on Windows drivers, there could be differences. The reverse 
engineering started with MIPS drivers for Linux. We never looked at any RE for 
Windows drivers.

A potential solution to your problem might be to use The method employed in 
http://www.lwfinger.com/b43-firmware/no_net_install_bcm43xx_firmware.tar.bz2. 
That tar file contains Broadcom object files with firmware for b43 and b43legacy 
with a script that extracts the firmware files. It meets Broadcom restrictions 
in that it only redistributes drivers, not firmware files. That particular tar 
file contains 5.100.138 b43 firmware; however, it would be easy to package a 
different driver, and adjust the extraction script accordingly. If it is not 
possible to package the tar file as part of your Windows installation, at least 
you could have your users download that file from a Windows boot, and then run 
the firmware extraction from a Linux boot.

The only thing I ask is that you host the download on your server. I do not 
promise to host those files in perpetuity. I wrote part of the script file, and 
you have my permission to use it as you please as long as you preserve my 
copyright. The rest of the script is part of the openSUSE package.

Larry




From jprvita at endlessm.com  Mon Jun 12 09:28:09 2017
From: jprvita at endlessm.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?=)
Date: Mon, 12 Jun 2017 12:28:09 -0400
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
 <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
 <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>
Message-ID: <CAOcMMic01a3On+va+x5_FcC_9Gz8xKhdjU1gbjQ0qYwN1CdSmQ@mail.gmail.com>

On Thu, Jun 8, 2017 at 12:48 AM, Larry Finger <Larry.Finger at lwfinger.net> wrote:
> On 06/07/2017 07:08 PM, Jo?o Paulo Rechi Vita
> A potential solution to your problem might be to use The method employed in
> http://www.lwfinger.com/b43-firmware/no_net_install_bcm43xx_firmware.tar.bz2.
> That tar file contains Broadcom object files with firmware for b43 and
> b43legacy with a script that extracts the firmware files. It meets Broadcom
> restrictions in that it only redistributes drivers, not firmware files. That
> particular tar file contains 5.100.138 b43 firmware; however, it would be
> easy to package a different driver, and adjust the extraction script
> accordingly. If it is not possible to package the tar file as part of your
> Windows installation, at least you could have your users download that file
> from a Windows boot, and then run the firmware extraction from a Linux boot.
>
> The only thing I ask is that you host the download on your server. I do not
> promise to host those files in perpetuity. I wrote part of the script file,
> and you have my permission to use it as you please as long as you preserve
> my copyright. The rest of the script is part of the openSUSE package.
>

We already ship a similar script based on the debian package for
b43-fwcutter (with some adaptations for our rootfs layout), that would
download the drivers, extract and install firmware for the user, so we
could just ship the files as well. What I was trying to avoid is
shipping those files, and that's where extracting from the Windows
drivers would come in handy.

Thanks,

......................................................................................
Jo?o Paulo Rechi Vita  |  +1.415.851.5778  |  Endless


From m at bues.ch  Mon Jun 12 09:59:43 2017
From: m at bues.ch (Michael =?UTF-8?B?QsO8c2No?=)
Date: Mon, 12 Jun 2017 18:59:43 +0200
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <CAOcMMic01a3On+va+x5_FcC_9Gz8xKhdjU1gbjQ0qYwN1CdSmQ@mail.gmail.com>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
 <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
 <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>
 <CAOcMMic01a3On+va+x5_FcC_9Gz8xKhdjU1gbjQ0qYwN1CdSmQ@mail.gmail.com>
Message-ID: <20170612185828.4e64b801@wiggum>

On Mon, 12 Jun 2017 12:28:09 -0400
Jo?o Paulo Rechi Vita <jprvita at endlessm.com> wrote:

> We already ship a similar script based on the debian package for
> b43-fwcutter (with some adaptations for our rootfs layout), that would
> download the drivers, extract and install firmware for the user, so we
> could just ship the files as well. What I was trying to avoid is
> shipping those files, and that's where extracting from the Windows
> drivers would come in handy.


Well, the problem is that it is very hard to get the names for the
firmware images found in the binary.

What you could do is try to find a Linux driver and a Windows driver
with exactly matching FW versions and then use the names from the Linux
driver to extract the blobs from the Windows driver.
It would be pretty easy to write a script that takes a Linux driver and
its matching extract-offsets and extract-names and then create the
corresponding offsets for the Windows binary.
Please feel free to create such a script and I would be happy to
include it in b43-fwcutter.

A script to auto-generate the extract-info from a Linux driver is
already included with b43-fwcutter.

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20170612/a26f16b7/attachment.sig>

From jprvita at endlessm.com  Thu Jun 15 15:21:40 2017
From: jprvita at endlessm.com (=?UTF-8?Q?Jo=C3=A3o_Paulo_Rechi_Vita?=)
Date: Thu, 15 Jun 2017 18:21:40 -0400
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <20170612185828.4e64b801@wiggum>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
 <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
 <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>
 <CAOcMMic01a3On+va+x5_FcC_9Gz8xKhdjU1gbjQ0qYwN1CdSmQ@mail.gmail.com>
 <20170612185828.4e64b801@wiggum>
Message-ID: <CAOcMMiexGBmnuiTPzzsux-wq8HUGejU4i=UckTapKe1YoAAsHQ@mail.gmail.com>

Hello again,

On Mon, Jun 12, 2017 at 12:59 PM, Michael B?sch <m at bues.ch> wrote:
> On Mon, 12 Jun 2017 12:28:09 -0400
> Jo?o Paulo Rechi Vita <jprvita at endlessm.com> wrote:
>
>> We already ship a similar script based on the debian package for
>> b43-fwcutter (with some adaptations for our rootfs layout), that would
>> download the drivers, extract and install firmware for the user, so we
>> could just ship the files as well. What I was trying to avoid is
>> shipping those files, and that's where extracting from the Windows
>> drivers would come in handy.
>
>
> Well, the problem is that it is very hard to get the names for the
> firmware images found in the binary.
>
> What you could do is try to find a Linux driver and a Windows driver
> with exactly matching FW versions and then use the names from the Linux
> driver to extract the blobs from the Windows driver.

We've been trying to do some binary grepping for the first 4 bytes of
the firmware files in the windows driver (grep -obUaP
"\x75\x01\x00\x00" BCMWL664.SYS), but although there are some matching
occurrences, after that the bytes start to differ. Any other
suggestions on trying to match the firmware files with windows
drivers?

> It would be pretty easy to write a script that takes a Linux driver and
> its matching extract-offsets and extract-names and then create the
> corresponding offsets for the Windows binary.
> Please feel free to create such a script and I would be happy to
> include it in b43-fwcutter.
>
> A script to auto-generate the extract-info from a Linux driver is
> already included with b43-fwcutter.
>

Yep, I have looked at that, and tried to objdump the windows driver,
but as you guys said, the symbol names are stripped out of it.

On a another topic, is there a license file available somewhere for
the wl MIPS drivers? I've downloaded the Asus/Netgear tarballs that
they were originally extracted from, but couldn't find a license for
the drivers there, just a general release notes file on the top dir,
and some un-related licenses for different projects used in the
router's rootfs image.

Thanks,

......................................................................................
Jo?o Paulo Rechi Vita  |  +1.415.851.5778  |  Endless


From m at bues.ch  Thu Jun 15 23:21:48 2017
From: m at bues.ch (Michael =?UTF-8?B?QsO8c2No?=)
Date: Fri, 16 Jun 2017 08:21:48 +0200
Subject: Using b43-fwcutter on Windows drivers
In-Reply-To: <CAOcMMiexGBmnuiTPzzsux-wq8HUGejU4i=UckTapKe1YoAAsHQ@mail.gmail.com>
References: <CAOcMMidabs11reb+t8rcop5z8AsiU13xcsT7-VYJXGO0RdUyWw@mail.gmail.com>
 <fca17d4a-21b8-9087-b0e0-41f183b70e89@lwfinger.net>
 <CAOcMMidd-qr8DZYyQCwHrejpVym64-nR9-_10nepm61GOT7Eow@mail.gmail.com>
 <bcf64bd7-ebf8-1876-3487-453c941ec7bc@lwfinger.net>
 <CAOcMMic01a3On+va+x5_FcC_9Gz8xKhdjU1gbjQ0qYwN1CdSmQ@mail.gmail.com>
 <20170612185828.4e64b801@wiggum>
 <CAOcMMiexGBmnuiTPzzsux-wq8HUGejU4i=UckTapKe1YoAAsHQ@mail.gmail.com>
Message-ID: <20170616082148.72f3f344@wiggum>

On Thu, 15 Jun 2017 18:21:40 -0400
Jo?o Paulo Rechi Vita <jprvita at endlessm.com> wrote:

> We've been trying to do some binary grepping for the first 4 bytes of
> the firmware files in the windows driver (grep -obUaP
> "\x75\x01\x00\x00" BCMWL664.SYS), but although there are some matching
> occurrences, after that the bytes start to differ. Any other
> suggestions on trying to match the firmware files with windows
> drivers?

Well, then you most likely have differing fw versions.
Try to find other binaries.

> On a another topic, is there a license file available somewhere for
> the wl MIPS drivers? I've downloaded the Asus/Netgear tarballs that
> they were originally extracted from, but couldn't find a license for
> the drivers there, just a general release notes file on the top dir,
> and some un-related licenses for different projects used in the
> router's rootfs image.

I don't know anything about the licensing.

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20170616/061c5758/attachment.sig>

From mohanbaral70 at gmail.com  Sun Jun 18 19:44:54 2017
From: mohanbaral70 at gmail.com (Mohan Baral)
Date: Mon, 19 Jun 2017 08:29:54 +0545
Subject: driver
Message-ID: <CABgTxPqiyTM7DXDoQ7HxVfZuE0=Yx1D5BX4C7QadBEaFx4ob6A@mail.gmail.com>

i couldn't turn on my card into monitor mode...
where could I get driver file as my
pci-id 14e4:4315
and chip id BCM4312


