From mboxrd@z Thu Jan 1 00:00:00 1970 From: Date: Thu, 07 Apr 2011 05:55:38 -0000 Subject: No subject Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org the silicon itself at power-on. 'abcd' sounds a bit too convenient to be what's in EEPROM/OTP; so maybe it's a default value in the silicon? (All just conjecture here at this point.) Adrian On 10 April 2011 23:17, Mohammed Shafi wrote: > On Sun, Apr 10, 2011 at 8:41 PM, Peter Stuge wrote: > > Mohammed Shafi wrote: > >> > Is this a serious proposal from Atheros, or just your attempt at > >> > a quick fix? > >> > >> No! its purely a personal idea (am completely responsible for the > >> mistake),and I will take a look at it carefully to fix this. > > > > Sorry, I didn't mean that you made a mistake, just that the > > suggestion probably would not get us closer to the actual issue. > > > > Bus level issues are indeed difficult. :\ > > thanks, i did not know that. thought simple as adding another device id. > > > > > >> > A device having an unexpected PCI id means that something is really > >> > wrong in the device or on the bus, and the solution is rarely to > >> > pretend that it didn't happen.] > >> > >> Yeah I can see that, hoping that I may get a correct Device ID from > >> the reporter. I dont think 'abcd' is a proper vendor id. > > > > Yes, it's easy to spot. The question is how we can find out *why* > > this happened, so that this error case can be prevented. > > Yes sure. > > > > > >> > Since this card should work fine in principle, maybe it's some issue > >> > with missing, or wrong, firmware stored on the Linux system. > >> > >> AR9382 does not seems to have firmware > > > > Aha! That's only for the USB devices maybe. I don't know much detail > > for these latest devices. > > > currently only ath9k_htc needs firmware. > > > > >> and you have any idea what might went wrong. > > > > Sorry, I don't understand what you mean here. > > Your suggestions about what might have went wrong, as you had already > told it might be a bus level issue. > > > > > > >> Also why its detected as Ethernet Controller rather than > >> Network controller. > > > > This string comes from the pciutils package and could easily have > > changed. Better look at the numerical device class code, which is > > what is read from hardware. > > thanks, I will look into that. > > > > > But I expect that when one thing in config space (device id) is bogus > > then the rest of config space is also quite possibly bogus, for the > > same reason, whatever it is. > > > > > > //Peter > > _______________________________________________ > > ath9k-devel mailing list > > ath9k-devel at lists.ath9k.org > > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > > > _______________________________________________ > ath9k-devel mailing list > ath9k-devel at lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel > --20cf300256ecb39f7b04a09232d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Incorrect or misplaced EEPROM/OTP data, perhaps?

From wh= at I gather, the PCI ID on earlier devices is loaded out of EEPROM by the s= ilicon itself at power-on. 'abcd' sounds a bit too convenient to be= what's in EEPROM/OTP; so maybe it's a default value in the silicon= ?

(All just conjecture here at this point.)

Adrian

= On 10 April 2011 23:17, Mohammed Shafi <shafi.ath9k at gmail.com> wrote:
On Sun, Apr 10, 2011 at 8= :41 PM, Peter Stuge <peter at stuge.se> wrote:
> Mohammed Shafi wrote:
>> > Is this a serious proposal from Atheros, or just your attempt= at
>> > a quick fix?
>>
>> No! its purely a personal idea (am completely responsible for the<= br> >> mistake),and I will take a look at it carefully to fix this.
>
> Sorry, I didn't mean that you made a mistake, just that the
> suggestion probably would not get us closer to the actual issue.
>
> Bus level issues are indeed difficult. :\

thanks, i did not know that. thought simple as adding another device = id.
>
>
>> > A device having an unexpected PCI id means that something is = really
>> > wrong in the device or on the bus, and the solution is rarely= to
>> > pretend that it didn't happen.]
>>
>> Yeah I can see that, hoping that I may get a correct Device ID fro= m
>> the reporter. I dont think 'abcd' is a proper vendor id. >
> Yes, it's easy to spot. The question is how we can find out *why*<= br> > this happened, so that this error case can be prevented.

Yes sure.
>
>
>> > Since this card should work fine in principle, maybe it's= some issue
>> > with missing, or wrong, firmware stored on the Linux system.<= br> >>
>> AR9382 does not seems to have firmware
>
> Aha! That's only for the USB devices maybe. I don't know much = detail
> for these latest devices.
>
currently only =A0ath9k_htc needs firmware.

>
>> and you have any idea what might went wrong.
>
> Sorry, I don't understand what you mean here.

Your suggestions about what might have went wrong, as you had already=
told it might be a bus level issue.

>
>
>> Also why its detected as Ethernet Controller rather than
>> Network controller.
>
> This string comes from the pciutils package and could easily have
> changed. Better look at the numerical device class code, which is
> what is read from hardware.

thanks, I will look into that.

--20cf300256ecb39f7b04a09232d4--