Re: SMC2662W V.4

Alex Schultz <[email protected]>
Newsgroups gmane.linux.drivers.at76c503a.user
Message-ID <[email protected]>
Hi,

I now might be able to mod it myself. I took a look at the at76c503.c 
file and found that the remap and where to put the delay is probably in 
that file too. The firmware changes could easily be done with a modded 
version of at76c505-rfmd2958.c and fw-505rfmd2958-1.101.0-86.h however, 
I don't know how to make at76c503.c behave differently when dealing with 
a SMC2662W V.4 rather than with other things. I could make it always 
behave as if it had the SMC2662W V.4, but I want to make a nice clean 
mod that could possibly be added to the main tree if it proves to be 
stable and the code is clean. So my main question now is, how would one 
make at76c503.c behave differently when using different models of 
at76c503 based network adapters?

    Al

Alex Schultz wrote:

> Hi,
>
> My friend is having troubles getting this driver to work with the SMC 
> 2662W V.4 . I did some research and found a BSD driver that works with 
> it (http://vitsch.net/bsd/atuwi/) . There seems to be some funny 
> quirks that it works around. Relevant parts of the code seem to be:
>
>    #ifndef ATUWI_NO_RFMD2958_SMC
>        /* SMC2662 V.4 */
>        { USB_VENDOR_ATMEL,    USB_PRODUCT_ATMEL_AT76C505A,
>          RadioRFMD2958_SMC,    ATUWI_QUIRK_NO_REMAP |
>    ATUWI_QUIRK_FW_DELAY },
>    #endif
>
>
> Just the general info about it
>
>    /*
>     * The SMC2662w V.4 seems to require some time to do it's thing with
>     * the external firmware... 20 ms isn't enough, but 21 ms works 100
>     * times out of 100 tries. We'll wait a bit longer just to be sure
>     */
>    if (sc->atuwi_quirk & ATUWI_QUIRK_FW_DELAY) {
>        atuwi_msleep(sc, 21 + 100);
>    }
>
>
> Seems that it has a funny quirk (explained well in the comment)
>
>    err = atuwi_usb_request(sc, DFU_REMAP, 0, 0, 0, NULL);
>    if ((err) && (! sc->atuwi_quirk & ATUWI_QUIRK_NO_REMAP)) {
>        ERROR(("atuwi%d: remap failed!\n", sc->atuwi_unit));
>        return err;
>    }
>
>
> Another quirk, something to do with remaps, seems to ignore what would 
> otherwise be a problem for other cards
>
>    #ifndef ATUWI_NO_RFMD2958_SMC
>        case RadioRFMD2958_SMC:
>            ptr=atuwi_fw_rfmd2958_smc_int;
>            bytes_left=sizeof(atuwi_fw_rfmd2958_smc_int);
>            DEBUG(FLAG_FW,("atuwi%d: loading RFMD2958-smc firmware...\n",
>                sc->atuwi_unit));
>            break;
>    #endif
>
>
> Apparently it needs it's own firmware
>
>    #ifndef ATUWI_NO_RFMD2958_SMC
>    #include <dev/usb/atuwi_rfmd2958-smc_fw.h>
>
>
> Again the new firmware
>
>    #ifndef ATUWI_NO_RFMD2958_SMC
>        case RadioRFMD2958_SMC:
>            ptr = atuwi_fw_rfmd2958_smc_ext;
>            bytes_left = sizeof(atuwi_fw_rfmd2958_smc_ext);
>            DEBUG(FLAG_FW,("atuwi%d: loading external RFMD2958-smc "
>                "firmware\n", sc->atuwi_unit));
>            break;
>    #endif
>
>
> and more about the new firmware.
> I don't have the programming experience to make a version of the 
> driver with support for these quirks, and I don't know if Jorg has the 
> time to impliment such things. I just though I'd mention what I've 
> found about this.
>
>
>          Al
>
> _______________________________________________
> at76c503a-user mailing list
> [email protected]
> http://lists.berlios.de/mailman/listinfo/at76c503a-user
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.