As I said off-list, I have several devices using 2313, 2315, and 2317 chips. I will continue to work with you to test the patches as they come through.
One aspect I would propose to add is to expose information like vendor Id sub vendor ID etc. so they can be associated properly by iwinfo to a particular make or model. Device detection worked fine in madwifi but is broken using ath5k. Last but not least we should hurry and apply changes quickly as long as atheros target in trunk and attitude adjustment are on the same kernel version so a back port to AA is easy to do. Finally thank you for taking the initiative. Kind Regards Hanno Schupp On 10/11/2012, at 12:11 AM, Jonathan Bither <jonbit...@gmail.com> wrote: > Good morning list, > I was writing to ask if there is a current maintainer for the Atheros > target that I may contact. > The reason that I ask is because I was contacted about a patch that I had > submitted prior in regards to allowing various EnGenius devices to > successfully reboot without a kernel hang. The patch didn't receive feedback > and was never accepted. > > I know that most maintainers have moved on to more common and higher > performance chipsets as of late, however there are still a lot of ar231x and > ar531x chipsets still in the field. > > I will be required to maintain updates on these chipsets for my company and > as such I would like to find the best way to submit various patches to the > target with the highest probability of getting accepted. Would me cloning the > OpenWRT mirror on github and submitting pull requests be sufficient, or would > each patch source have to be sent through the mailing list? > > Currently the target is setup through patch sets. I know that this was > intended so that the platform could ultimately be mainlined into the kernel > easily. I ask if I may break apart the patch sets into the 'files-3.x' > overlay layout temporarily as other targets have, so that I may be able to > submit various patches in a more timely manner as opposed to patching patch > sets. These could just as easily be transferred into patch form again in the > event of a push to get the target mainlined. > > On my TODO: > Remove duplicate code between the ar231x and ar531x platforms. > Address all gpio/led polling flash errors. > Determine the hardware limitation of the CPU processing/Ethernet speed. > Add ethtool support to the Ethernet driver. > Add BQL to the Ethernet driver. > Rewrite sections of the Ethernet driver for maximum performance. > Add gpio detection mechanisms to address EnGenius products cleanly. > > Any feedback is greatly appreciated. > > Thanks, > Jonathan Bither _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
