diff for duplicates of <49AE851B.2070709@openwrt.org> diff --git a/a/1.txt b/N1/1.txt index 63722df..b534fca 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,70 +1,97 @@ -Sujith ?rta: +Sujith =EDrta: > Gabor Juhos wrote: >> 1. In some cases the ethernet interface goes down for a short time >> after'ifconfig wlan0 up'. ->> 2. Sometimes the device simply reboots itself after 'ifconfig wlan0 up'. +>> 2. Sometimes the device simply reboots itself after 'ifconfig wlan0 = +up'. >> ->> After I have added some printk statements into the code, I noticed that the ->> ar5416 and ar9100 devices use the same initval arrays currently. I assume ->> that they requires different initialization, because we have different +>> After I have added some printk statements into the code, I noticed t= +hat the +>> ar5416 and ar9100 devices use the same initval arrays currently. I a= +ssume +>> that they requires different initialization, because we have differe= +nt >> arrays for them. >> -> +>=20 > Yep, this is a bug, and AR_SREV_9100_OR_LATER is probably wrong. Ok. -> ->> Although I have no detailed knowledge about the evolution of the ath9k devices, ->> but the version checking macros for ther AR5416 cards seemed weird enough, so I ->> have replaced them. Unfortunately, this leaded to very bad performance with the ->> ar5416 cards I have, but the driver was working on the ar913x boards. +>=20 +>> Although I have no detailed knowledge about the evolution of the ath= +9k devices, +>> but the version checking macros for ther AR5416 cards seemed weird e= +nough, so I +>> have replaced them. Unfortunately, this leaded to very bad performan= +ce with the +>> ar5416 cards I have, but the driver was working on the ar913x boards= +=2E >> ->> After some digging, I have found an interesting ifdef statement in Sam's current ->> HAL. In his ar5416Common initval array, this ifdef conditionally selects the ->> right RTC register offsets for the ar5416/ar9100 devices. The strange thing, ->> that in the ath9k driver the ar5416 specific RTC register offsets are used in ->> the ar5416Common_ar9100 array, while the ar9100 specific offsets are used in the +>> After some digging, I have found an interesting ifdef statement in S= +am's current +>> HAL. In his ar5416Common initval array, this ifdef conditionally sel= +ects the +>> right RTC register offsets for the ar5416/ar9100 devices. The strang= +e thing, +>> that in the ath9k driver the ar5416 specific RTC register offsets ar= +e used in +>> the ar5416Common_ar9100 array, while the ar9100 specific offsets are= + used in the >> ar5416Common. >> -> +>=20 > I'll check the initval arrays and update. -> +>=20 >> +#define AR_SREV_5416(_ah) \ ->> + (((_ah)->hw_version.macVersion == AR_SREV_VERSION_5416_PCIE) || \ ->> + ((_ah)->hw_version.macVersion == AR_SREV_VERSION_5416_PCI)) +>> + (((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_5416_P= +CIE) || \ +>> + ((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_5416_PC= +I)) >> +#define AR_SREV_5416_V20_OR_LATER(_ah) \ ->> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) || \ +>> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) = +|| \ >> + ((AR_SREV_5416(_ah)) && \ ->> + ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_20))) +>> + ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416_20))) >> +#define AR_SREV_5416_V22_OR_LATER(_ah) \ ->> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) || \ +>> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) = +|| \ >> + ((AR_SREV_5416(_ah)) && \ ->> + ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_22))) +>> + ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416_22))) >> + -> -> Hm, the 5416_V1, 5416_V2 macros have to check 3 different HW (5416, 9100, 9160). +>=20 +> Hm, the 5416_V1, 5416_V2 macros have to check 3 different HW (5416, 9= +100, 9160). -I don't see any 5416_V1 macro here. The AR_SREV_5416 should check the silicon -revision of the AR5416 cards only. But if we would be consistent, we should have -a _V10_OR_LATER although i don't see where it would be useful. The _V20_OR_LATER -and the _V22_OR_LATER macro I proposed above will cover the 9100 and 9160 chips. +I don't see any 5416_V1 macro here. The AR_SREV_5416 should check the s= +ilicon +revision of the AR5416 cards only. But if we would be consistent, we sh= +ould have +a _V10_OR_LATER although i don't see where it would be useful. The _V20= +_OR_LATER +and the _V22_OR_LATER macro I proposed above will cover the 9100 and 91= +60 chips. -> +>=20 >> +#define AR_SREV_9100(ah) \ ->> + ((ah->hw_version.macVersion) == AR_SREV_VERSION_9100) +>> + ((ah->hw_version.macVersion) =3D=3D AR_SREV_VERSION_9100) >> #define AR_SREV_9100_OR_LATER(_ah) \ ->> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_5416_PCIE)) +>> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_5416_PCI= +E)) >> -#define AR_SREV_5416_20_OR_LATER(_ah) \ ->> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9160) || \ ->> - ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_20)) +>> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9160) ||= + \ +>> - ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416= +_20)) >> -#define AR_SREV_5416_22_OR_LATER(_ah) \ ->> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9160) || \ ->> - ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_22)) ->> + ((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9100) +>> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9160) ||= + \ +>> - ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416= +_22)) +>> + ((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9100) >> + >> #define AR_SREV_9160(_ah) \ ->> (((_ah)->hw_version.macVersion == AR_SREV_VERSION_9160)) +>> (((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_9160)) >> #define AR_SREV_9160_10_OR_LATER(_ah) \ >> -- >> 1.5.3.2 @@ -72,3 +99,8 @@ and the _V22_OR_LATER macro I proposed above will cover the 9100 and 9160 chips. Regards, Gabor +-- +To unsubscribe from this list: send the line "unsubscribe linux-wireles= +s" in +the body of a message to majordomo@vger.kernel.org +More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 10ac2f2..8cd594e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,84 +1,120 @@ "ref\01236103846-1672-1-git-send-email-juhosg@openwrt.org\0" "ref\018862.1025.217829.656599@gargle.gargle.HOWL\0" "From\0Gabor Juhos <juhosg@openwrt.org>\0" - "Subject\0[ath9k-devel] [RFC] ath9k: use correct init values for ar9100 devices\0" + "Subject\0Re: [RFC] ath9k: use correct init values for ar9100 devices\0" "Date\0Wed, 04 Mar 2009 14:41:47 +0100\0" - "To\0ath9k-devel@lists.ath9k.org\0" + "To\0Sujith <Sujith.Manoharan@atheros.com>\0" + "Cc\0John W. Linville <linville@tuxdriver.com>" + ath9k-devel@lists.ath9k.org <ath9k-devel@lists.ath9k.org> + linux-wireless@vger.kernel.org <linux-wireless@vger.kernel.org> + " Imre Kaloz <kaloz@openwrt.org>\0" "\00:1\0" "b\0" - "Sujith ?rta:\n" + "Sujith =EDrta:\n" "> Gabor Juhos wrote:\n" ">> 1. In some cases the ethernet interface goes down for a short time\n" ">> after'ifconfig wlan0 up'.\n" - ">> 2. Sometimes the device simply reboots itself after 'ifconfig wlan0 up'.\n" + ">> 2. Sometimes the device simply reboots itself after 'ifconfig wlan0 =\n" + "up'.\n" ">>\n" - ">> After I have added some printk statements into the code, I noticed that the\n" - ">> ar5416 and ar9100 devices use the same initval arrays currently. I assume\n" - ">> that they requires different initialization, because we have different\n" + ">> After I have added some printk statements into the code, I noticed t=\n" + "hat the\n" + ">> ar5416 and ar9100 devices use the same initval arrays currently. I a=\n" + "ssume\n" + ">> that they requires different initialization, because we have differe=\n" + "nt\n" ">> arrays for them.\n" ">>\n" - "> \n" + ">=20\n" "> Yep, this is a bug, and AR_SREV_9100_OR_LATER is probably wrong.\n" "\n" "Ok.\n" "\n" - "> \n" - ">> Although I have no detailed knowledge about the evolution of the ath9k devices,\n" - ">> but the version checking macros for ther AR5416 cards seemed weird enough, so I\n" - ">> have replaced them. Unfortunately, this leaded to very bad performance with the\n" - ">> ar5416 cards I have, but the driver was working on the ar913x boards.\n" + ">=20\n" + ">> Although I have no detailed knowledge about the evolution of the ath=\n" + "9k devices,\n" + ">> but the version checking macros for ther AR5416 cards seemed weird e=\n" + "nough, so I\n" + ">> have replaced them. Unfortunately, this leaded to very bad performan=\n" + "ce with the\n" + ">> ar5416 cards I have, but the driver was working on the ar913x boards=\n" + "=2E\n" ">>\n" - ">> After some digging, I have found an interesting ifdef statement in Sam's current\n" - ">> HAL. In his ar5416Common initval array, this ifdef conditionally selects the\n" - ">> right RTC register offsets for the ar5416/ar9100 devices. The strange thing,\n" - ">> that in the ath9k driver the ar5416 specific RTC register offsets are used in\n" - ">> the ar5416Common_ar9100 array, while the ar9100 specific offsets are used in the\n" + ">> After some digging, I have found an interesting ifdef statement in S=\n" + "am's current\n" + ">> HAL. In his ar5416Common initval array, this ifdef conditionally sel=\n" + "ects the\n" + ">> right RTC register offsets for the ar5416/ar9100 devices. The strang=\n" + "e thing,\n" + ">> that in the ath9k driver the ar5416 specific RTC register offsets ar=\n" + "e used in\n" + ">> the ar5416Common_ar9100 array, while the ar9100 specific offsets are=\n" + " used in the\n" ">> ar5416Common.\n" ">>\n" - "> \n" + ">=20\n" "> I'll check the initval arrays and update.\n" - "> \n" + ">=20\n" ">> +#define AR_SREV_5416(_ah) \\\n" - ">> + (((_ah)->hw_version.macVersion == AR_SREV_VERSION_5416_PCIE) || \\\n" - ">> + ((_ah)->hw_version.macVersion == AR_SREV_VERSION_5416_PCI))\n" + ">> + (((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_5416_P=\n" + "CIE) || \\\n" + ">> + ((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_5416_PC=\n" + "I))\n" ">> +#define AR_SREV_5416_V20_OR_LATER(_ah) \\\n" - ">> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) || \\\n" + ">> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) =\n" + "|| \\\n" ">> + ((AR_SREV_5416(_ah)) && \\\n" - ">> + ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_20)))\n" + ">> + ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416_20)))\n" ">> +#define AR_SREV_5416_V22_OR_LATER(_ah) \\\n" - ">> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) || \\\n" + ">> + (((_ah)->hw_version.macVersion > AR_SREV_VERSION_5416_PCIE) =\n" + "|| \\\n" ">> + ((AR_SREV_5416(_ah)) && \\\n" - ">> + ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_22)))\n" + ">> + ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416_22)))\n" ">> +\n" - "> \n" - "> Hm, the 5416_V1, 5416_V2 macros have to check 3 different HW (5416, 9100, 9160).\n" + ">=20\n" + "> Hm, the 5416_V1, 5416_V2 macros have to check 3 different HW (5416, 9=\n" + "100, 9160).\n" "\n" - "I don't see any 5416_V1 macro here. The AR_SREV_5416 should check the silicon\n" - "revision of the AR5416 cards only. But if we would be consistent, we should have\n" - "a _V10_OR_LATER although i don't see where it would be useful. The _V20_OR_LATER\n" - "and the _V22_OR_LATER macro I proposed above will cover the 9100 and 9160 chips.\n" + "I don't see any 5416_V1 macro here. The AR_SREV_5416 should check the s=\n" + "ilicon\n" + "revision of the AR5416 cards only. But if we would be consistent, we sh=\n" + "ould have\n" + "a _V10_OR_LATER although i don't see where it would be useful. The _V20=\n" + "_OR_LATER\n" + "and the _V22_OR_LATER macro I proposed above will cover the 9100 and 91=\n" + "60 chips.\n" "\n" - "> \n" + ">=20\n" ">> +#define AR_SREV_9100(ah) \\\n" - ">> + ((ah->hw_version.macVersion) == AR_SREV_VERSION_9100)\n" + ">> + ((ah->hw_version.macVersion) =3D=3D AR_SREV_VERSION_9100)\n" ">> #define AR_SREV_9100_OR_LATER(_ah) \\\n" - ">> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_5416_PCIE))\n" + ">> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_5416_PCI=\n" + "E))\n" ">> -#define AR_SREV_5416_20_OR_LATER(_ah) \\\n" - ">> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9160) || \\\n" - ">> - ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_20))\n" + ">> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9160) ||=\n" + " \\\n" + ">> - ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416=\n" + "_20))\n" ">> -#define AR_SREV_5416_22_OR_LATER(_ah) \\\n" - ">> - (((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9160) || \\\n" - ">> - ((_ah)->hw_version.macRev >= AR_SREV_REVISION_5416_22))\n" - ">> + ((_ah)->hw_version.macVersion >= AR_SREV_VERSION_9100)\n" + ">> - (((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9160) ||=\n" + " \\\n" + ">> - ((_ah)->hw_version.macRev >=3D AR_SREV_REVISION_5416=\n" + "_22))\n" + ">> + ((_ah)->hw_version.macVersion >=3D AR_SREV_VERSION_9100)\n" ">> +\n" ">> #define AR_SREV_9160(_ah) \\\n" - ">> (((_ah)->hw_version.macVersion == AR_SREV_VERSION_9160))\n" + ">> (((_ah)->hw_version.macVersion =3D=3D AR_SREV_VERSION_9160))\n" ">> #define AR_SREV_9160_10_OR_LATER(_ah) \\\n" ">> --\n" ">> 1.5.3.2\n" ">>\n" "\n" "Regards,\n" - Gabor + "Gabor\n" + "--\n" + "To unsubscribe from this list: send the line \"unsubscribe linux-wireles=\n" + "s\" in\n" + "the body of a message to majordomo@vger.kernel.org\n" + More majordomo info at http://vger.kernel.org/majordomo-info.html -ec4eaaabae0bcc642dab5ee3b911a11deb3d3d2aeaf7d119d86fc934ad6a9ef0 +59badc379cb5c4fb23fbb7e3e9e7b5218114b99ed67b6fb0c8f72c443fb06dd3
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.