| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAAF_D9iNZWEPzQg8T4T37n3=-BjVNJSSBOK5QGjZ7NGSh8cwpA@mail.gmail.com>
Date: Thu, 8 Nov 2012 21:11:27 +0600
From: Muhammad Minhazul Haque <mdminhazulhaque@...il.com>
To: Kevin McKinney <klmckinney1@...il.com>,
linux-kernel@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Rinat Camalov <richman1000000d@...il.com>,
devel@...verdev.osuosl.org
Subject: [PATCH] bcm_wimax.ko - Modified supported device list
Mr. Kevin,
I was never reported for that product id 0x0132. Yet you can continue
support for it if it is rare. In the meantime, we can add more devices
to the header and add those names to "usb_device_id" table in
"InterfaceInit.c". I added a new product string
"BCM_USB_PRODUCT_ID_ZTE_326" and also modified the device id table.
Again, I removed product if 0xbccd because Beceem, ZTE, Sprint use
this id for the block device containing device driver. Again, this is
always switched to base product id via udev. Here is my dmesg output
when udev is turned off.
=====
root@...piron:~# dmesg -c
[24449.439134] cdrom: issuing MRW background format suspend
[24459.102669] usb 2-1.2: new high-speed USB device number 11 using ehci_hcd
[24459.336258] scsi11 : usb-storage 2-1.2:1.0
[24460.334906] scsi 11:0:0:0: CD-ROM BCM-CD V 01.02 01.01
1.13 PQ: 0 ANSI: 2
[24460.336721] sr0: scsi3-mmc drive: 0x/0x xa/form2 tray
[24460.336971] sr 11:0:0:0: Attached scsi CD-ROM sr0
[24460.337167] sr 11:0:0:0: Attached scsi generic sg1 type 5
root@...piron:~# mount /dev/sr1 /media/tmp
mount: block device /dev/sr1 is write-protected, mounting read-only
=====
I did build after these changes and probed the module. It works
perfectly. I also tested 0x0172 and 0x0173. No error is reported. So I
assure that these products are valid. Not sure about 0x0132. Here is
the modinfo output.
=====
license: GPL
version: 5.2.45
description: Beceem Communications Inc. WiMAX driver
srcversion: 6968AC3635745331FE6470D
alias: usb:v19D2p0132d*dc*dsc*dp*ic*isc*ip*
alias: usb:v19D2p0007d*dc*dsc*dp*ic*isc*ip*
alias: usb:v19D2p0173d*dc*dsc*dp*ic*isc*ip*
alias: usb:v19D2p0172d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0489pE017d*dc*dsc*dp*ic*isc*ip*
alias: usb:v198Fp015Ed*dc*dsc*dp*ic*isc*ip*
alias: usb:v198Fp0300d*dc*dsc*dp*ic*isc*ip*
alias: usb:v198Fp0220d*dc*dsc*dp*ic*isc*ip*
alias: usb:v198Fp0210d*dc*dsc*dp*ic*isc*ip*
depends:
vermagic: 3.2.0-32-generic-pae SMP mod_unload modversions 686
parm: debug:Debug level (0=none,...,16=all) (uint)
=====
This patch is currently against a linux 3.7-rc4 kernel, for the x86
architecture.
diffstat for this patch is:
=====
{bcm => bcm.orig}/InterfaceInit.c | 5 ++---
{bcm => bcm.orig}/InterfaceInit.h | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
=====
To use the patch, remove module if it is probed. Build, and then probe.
About the TODO: I currently have a solution to make the device work.
It is not from Intel's wimax stack. I used Beceem's API. Can we
discuss on this?
Please let me know any feedback you have on this patch or the approach used.
Thanks,
Muhammad Minhazul Haque
Signed-off-by: Muhammad Minhazul Haque <mdminhazulhaque@...il.com>
On Wed, Nov 7, 2012 at 10:06 PM, Kevin McKinney <klmckinney1@...il.com> wrote:
> On Wed, Nov 7, 2012 at 3:21 AM, Greg Kroah-Hartman
> <gregkh@...ux-foundation.org> wrote:
>> Hi Muhammad, Linus forwarded me your email about this topic, hope that's
>> ok. See the bottom for my comments, the entire email is quoted to get
>> Kevin up to speed on this.
>>
>>> ---------- Forwarded message ----------
>>> From: "Muhammad Minhazul Haque" <mdminhazulhaque@...il.com>
>>> Date: Nov 5, 2012 7:00 PM
>>> Subject: About Beceem WiMAX Module
>>> To: <torvalds@...ux-foundation.org>
>>>
>>> Hello Sir,
>>>
>>> I have an issue with a module named "bcm_wimax". This is a staging
>>> module located at linux/drivers/staging/bcm. The problem is that, the
>>> supported devices listed in the module are not all valid or there are
>>> more to be added.
>>>
>>> "modinfo bcm_wimax" returns the supported product and vendor ids.
>>>
>>> ...
>>> alias: usb:v19D2p0007d*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v0489pE017d*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v19D2p0132d*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v198FpBCCDd*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v198Fp0220d*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v198Fp0210d*dc*dsc*dp*ic*isc*ip*
>>> alias: usb:v198Fp0300d*dc*dsc*dp*ic*isc*ip*
>>> ...
>>>
>>> Here the product id 198f:bccd is obsolete cause it is a storage device
>>> to load device driver which uses module "usb_storage". There are more
>>> devices with id 19d2:0172, 19d2:0173 and so on. They all have
>>> "beceXXXX" chip inside and the module "bcm_wimax" works fine with
>>> them. The only problem is, custom modules are to be build before using
>>> them and remove the original one. It would be great if more device id
>>> is added and remove which are rarely used. I often get emails from
>
> If device id "0x132" is rarely used, then I think we still have to support it.
>
>>> people using Virgin Mobile U760, Franklin Wireless u600 etc which have
>>> another device ids.
>>>
>>> I did a commit on your repo at
>>> https://github.com/torvalds/linux/blob/master/drivers/staging/bcm/
>>> InterfaceInit.h.
>>>
>>> At line 14, the following text
>>>
>>> #define BCM_USB_PRODUCT_ID_226 0x0132 /* not sure if this is valid */
>>>
>>> was changed to
>>>
>>> #define BCM_USB_PRODUCT_ID_226 0x0173 /* ZTE AX326 */
>>>
>>> Shouldn't this be approved?
>>>
>>> I have devices with id 19d2:0172, 19d2:0173, 198f:015e also. So if any
>>> help will be provided if anyone is interested. Feel free to ask any
>>> question regarding this device/module/api.
>>
>> Kevin, you added the "not sure if this is valid" comment here, should it
>> be removed? And we should just add the 0x173 device id also, right?
>
> I submitted a patch a while back (Sep 11, 2012) to add device id of
> "0x172" to the staging-next branch. I did not remove device id of
> "0x132" because I was not certain if it was valid. If Muhammad can
> confirm that this device id is not needed, then we should remove it.
> However, if it is used, but only rarely; I think we still need to
> support it.
>
> Muhammad, is that device id totally invalid, or is it valid but rarely used?
>
>> Muhammad, can you send me a patch for this in the format described in
>> Documentation/SubmittingPatches so that I can add the new device id to
>> the driver? And if you have people reporting other device ids, please
>> also send on those changes as well.
>>
>
> Thanks,
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists