| Message ID | 1391971686-9517-10-git-send-email-richard@nod.at |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
This description seems very incomplete as the symbol
is being used quite a bit and the code the symbol
controls is being deleted as well as the symbol.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2014-02-09 at 11:09 -0800, Joe Perches wrote: > On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote: > > The symbol is an orphan, get rid of it. > > This description seems very incomplete as the symbol > is being used quite a bit and the code the symbol > controls is being deleted as well as the symbol. Just yesterday I once again raised this issue (see https://lkml.org/lkml/2014/2/8/248 ). My patch - which dates form May 2013 - removes quite a bit more than Richard's patch. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 09.02.2014 20:18, schrieb Hauke Mehrtens: > On 02/09/2014 07:47 PM, Richard Weinberger wrote: >> The symbol is an orphan, get rid of it. >> >> Signed-off-by: Richard Weinberger <richard@nod.at> >> --- >> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >> 4 files changed, 5 insertions(+), 54 deletions(-) >> > > This code is used in OpenWrt with an out of tree arch code for the > Atheros 231x/531x SoC. [0] I do not think anyone is working on adding > this code to mainline Linux kernel, because of lack of time/interest. Sorry, we don't maintain out of tree code. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: > Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>> The symbol is an orphan, get rid of it. >>> >>> Signed-off-by: Richard Weinberger <richard@nod.at> >>> --- >>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>> 4 files changed, 5 insertions(+), 54 deletions(-) >>> >> >> This code is used in OpenWrt with an out of tree arch code for the >> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >> this code to mainline Linux kernel, because of lack of time/interest. > > Sorry, we don't maintain out of tree code. > Oleksij, Jonathan do you still working to make ar231x devices work with upstream, since your posts [1, 2]? Or may be someone from OpenWRT team would like to add upstream support? 1. https://lkml.org/lkml/2013/5/13/321 2. https://lkml.org/lkml/2013/5/13/358
Am 10.02.2014 13:05, schrieb Sergey Ryazanov: > 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: >> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>>> The symbol is an orphan, get rid of it. >>>> >>>> Signed-off-by: Richard Weinberger <richard@nod.at> >>>> --- >>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>>> 4 files changed, 5 insertions(+), 54 deletions(-) >>>> >>> >>> This code is used in OpenWrt with an out of tree arch code for the >>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >>> this code to mainline Linux kernel, because of lack of time/interest. >> >> Sorry, we don't maintain out of tree code. >> > > Oleksij, Jonathan do you still working to make ar231x devices work > with upstream, since your posts [1, 2]? Or may be someone from OpenWRT > team would like to add upstream support? > > 1. https://lkml.org/lkml/2013/5/13/321 > 2. https://lkml.org/lkml/2013/5/13/358 > Hi, my current target was to provide barebox and openocd support. - ar2313 is already upstream on barebox. - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. - openocd (EJTAG) support is ready and i'll push it ASUP. I hope Jonathan do kernel part. If not, i can provide some work, since i have testing boards and expiriance on this hardware.
2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>: > Am 10.02.2014 13:05, schrieb Sergey Ryazanov: >> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: >>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>>>> The symbol is an orphan, get rid of it. >>>>> >>>>> Signed-off-by: Richard Weinberger <richard@nod.at> >>>>> --- >>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>>>> 4 files changed, 5 insertions(+), 54 deletions(-) >>>>> >>>> >>>> This code is used in OpenWrt with an out of tree arch code for the >>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >>>> this code to mainline Linux kernel, because of lack of time/interest. >>> >>> Sorry, we don't maintain out of tree code. >>> >> >> Oleksij, Jonathan do you still working to make ar231x devices work >> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT >> team would like to add upstream support? >> >> 1. https://lkml.org/lkml/2013/5/13/321 >> 2. https://lkml.org/lkml/2013/5/13/358 >> > > Hi, > my current target was to provide barebox and openocd support. > - ar2313 is already upstream on barebox. > - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. > - openocd (EJTAG) support is ready and i'll push it ASUP. > WOW, Impressive. > I hope Jonathan do kernel part. If not, i can provide some work, since i > have testing boards and expiriance on this hardware. > If you need, I can test kernel part, or even do some porting work. I have some AR231x based boards, e.g. Ubnt LS2 and NS2.
2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: > 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>: >> Am 10.02.2014 13:05, schrieb Sergey Ryazanov: >>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: >>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>>>>> The symbol is an orphan, get rid of it. >>>>>> >>>>>> Signed-off-by: Richard Weinberger <richard@nod.at> >>>>>> --- >>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>>>>> 4 files changed, 5 insertions(+), 54 deletions(-) >>>>>> >>>>> >>>>> This code is used in OpenWrt with an out of tree arch code for the >>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >>>>> this code to mainline Linux kernel, because of lack of time/interest. >>>> >>>> Sorry, we don't maintain out of tree code. >>>> >>> >>> Oleksij, Jonathan do you still working to make ar231x devices work >>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT >>> team would like to add upstream support? >>> >>> 1. https://lkml.org/lkml/2013/5/13/321 >>> 2. https://lkml.org/lkml/2013/5/13/358 >>> >> >> Hi, >> my current target was to provide barebox and openocd support. >> - ar2313 is already upstream on barebox. >> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. >> - openocd (EJTAG) support is ready and i'll push it ASUP. >> > WOW, Impressive. That's a nice toy project, although since there are is an existing bootloader with sources, I would have shifted the priority towards getting the kernel support merged such that the bootloader can be used for something. BTW I sent a few devices to Jonathan, not sure if he ever got those... > >> I hope Jonathan do kernel part. If not, i can provide some work, since i >> have testing boards and expiriance on this hardware. >> > If you need, I can test kernel part, or even do some porting work. I > have some AR231x based boards, e.g. Ubnt LS2 and NS2. I guess you could start splitting the OpenWrt patches into a format that makes them suitable for being merged upstream and starting with the MIPS parts. There might be a bunch of checkpatch.pl cleanup work to do before getting those submitted.
2014-02-11 2:37 GMT+04:00 Florian Fainelli <florian@openwrt.org>: > 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: >> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>: >>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov: >>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: >>>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >>>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>>>>>> The symbol is an orphan, get rid of it. >>>>>>> >>>>>>> Signed-off-by: Richard Weinberger <richard@nod.at> >>>>>>> --- >>>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>>>>>> 4 files changed, 5 insertions(+), 54 deletions(-) >>>>>>> >>>>>> >>>>>> This code is used in OpenWrt with an out of tree arch code for the >>>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >>>>>> this code to mainline Linux kernel, because of lack of time/interest. >>>>> >>>>> Sorry, we don't maintain out of tree code. >>>>> >>>> >>>> Oleksij, Jonathan do you still working to make ar231x devices work >>>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT >>>> team would like to add upstream support? >>>> >>>> 1. https://lkml.org/lkml/2013/5/13/321 >>>> 2. https://lkml.org/lkml/2013/5/13/358 >>>> >>> >>> Hi, >>> my current target was to provide barebox and openocd support. >>> - ar2313 is already upstream on barebox. >>> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. >>> - openocd (EJTAG) support is ready and i'll push it ASUP. >>> >> WOW, Impressive. > > That's a nice toy project, although since there are is an existing > bootloader with sources, I would have shifted the priority towards > getting the kernel support merged such that the bootloader can be used > for something. BTW I sent a few devices to Jonathan, not sure if he > ever got those... > >> >>> I hope Jonathan do kernel part. If not, i can provide some work, since i >>> have testing boards and expiriance on this hardware. >>> >> If you need, I can test kernel part, or even do some porting work. I >> have some AR231x based boards, e.g. Ubnt LS2 and NS2. > > I guess you could start splitting the OpenWrt patches into a format > that makes them suitable for being merged upstream and starting with > the MIPS parts. There might be a bunch of checkpatch.pl cleanup work > to do before getting those submitted. I will do that if Jonathan does not have a working solution, which he would like to push upstream. So, let's wait for his reply.
2014-02-11 3:43 GMT+04:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: > 2014-02-11 2:37 GMT+04:00 Florian Fainelli <florian@openwrt.org>: >> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: >>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>: >>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov: >>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: >>>>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: >>>>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: >>>>>>>> The symbol is an orphan, get rid of it. >>>>>>>> >>>>>>>> Signed-off-by: Richard Weinberger <richard@nod.at> >>>>>>>> --- >>>>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- >>>>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- >>>>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- >>>>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- >>>>>>>> 4 files changed, 5 insertions(+), 54 deletions(-) >>>>>>>> >>>>>>> >>>>>>> This code is used in OpenWrt with an out of tree arch code for the >>>>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding >>>>>>> this code to mainline Linux kernel, because of lack of time/interest. >>>>>> >>>>>> Sorry, we don't maintain out of tree code. >>>>>> >>>>> >>>>> Oleksij, Jonathan do you still working to make ar231x devices work >>>>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT >>>>> team would like to add upstream support? >>>>> >>>>> 1. https://lkml.org/lkml/2013/5/13/321 >>>>> 2. https://lkml.org/lkml/2013/5/13/358 >>>>> >>>> >>>> Hi, >>>> my current target was to provide barebox and openocd support. >>>> - ar2313 is already upstream on barebox. >>>> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. >>>> - openocd (EJTAG) support is ready and i'll push it ASUP. >>>> >>> WOW, Impressive. >> >> That's a nice toy project, although since there are is an existing >> bootloader with sources, I would have shifted the priority towards >> getting the kernel support merged such that the bootloader can be used >> for something. BTW I sent a few devices to Jonathan, not sure if he >> ever got those... >> >>> >>>> I hope Jonathan do kernel part. If not, i can provide some work, since i >>>> have testing boards and expiriance on this hardware. >>>> >>> If you need, I can test kernel part, or even do some porting work. I >>> have some AR231x based boards, e.g. Ubnt LS2 and NS2. >> >> I guess you could start splitting the OpenWrt patches into a format >> that makes them suitable for being merged upstream and starting with >> the MIPS parts. There might be a bunch of checkpatch.pl cleanup work >> to do before getting those submitted. > > I will do that if Jonathan does not have a working solution, which he > would like to push upstream. So, let's wait for his reply. > John, can you delay the merging of this patch for a few months, I will try to prepare the necessary patches to add AR231x architecture to the kernel and send them to linux-mips.
On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote: > 2014-02-11 3:43 GMT+04:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: > > 2014-02-11 2:37 GMT+04:00 Florian Fainelli <florian@openwrt.org>: > >> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <ryazanov.s.a@gmail.com>: > >>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <linux@rempel-privat.de>: > >>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov: > >>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard@nod.at>: > >>>>>> Am 09.02.2014 20:18, schrieb Hauke Mehrtens: > >>>>>>> On 02/09/2014 07:47 PM, Richard Weinberger wrote: > >>>>>>>> The symbol is an orphan, get rid of it. > >>>>>>>> > >>>>>>>> Signed-off-by: Richard Weinberger <richard@nod.at> > >>>>>>>> --- > >>>>>>>> drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- > >>>>>>>> drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- > >>>>>>>> drivers/net/wireless/ath/ath5k/base.c | 14 -------------- > >>>>>>>> drivers/net/wireless/ath/ath5k/led.c | 7 ------- > >>>>>>>> 4 files changed, 5 insertions(+), 54 deletions(-) > >>>>>>>> > >>>>>>> > >>>>>>> This code is used in OpenWrt with an out of tree arch code for the > >>>>>>> Atheros 231x/531x SoC. [0] I do not think anyone is working on adding > >>>>>>> this code to mainline Linux kernel, because of lack of time/interest. > >>>>>> > >>>>>> Sorry, we don't maintain out of tree code. > >>>>>> > >>>>> > >>>>> Oleksij, Jonathan do you still working to make ar231x devices work > >>>>> with upstream, since your posts [1, 2]? Or may be someone from OpenWRT > >>>>> team would like to add upstream support? > >>>>> > >>>>> 1. https://lkml.org/lkml/2013/5/13/321 > >>>>> 2. https://lkml.org/lkml/2013/5/13/358 > >>>>> > >>>> > >>>> Hi, > >>>> my current target was to provide barebox and openocd support. > >>>> - ar2313 is already upstream on barebox. > >>>> - ar2315-2318 (barebox) awaiting review by Anthony Pavlov. > >>>> - openocd (EJTAG) support is ready and i'll push it ASUP. > >>>> > >>> WOW, Impressive. > >> > >> That's a nice toy project, although since there are is an existing > >> bootloader with sources, I would have shifted the priority towards > >> getting the kernel support merged such that the bootloader can be used > >> for something. BTW I sent a few devices to Jonathan, not sure if he > >> ever got those... > >> > >>> > >>>> I hope Jonathan do kernel part. If not, i can provide some work, since i > >>>> have testing boards and expiriance on this hardware. > >>>> > >>> If you need, I can test kernel part, or even do some porting work. I > >>> have some AR231x based boards, e.g. Ubnt LS2 and NS2. > >> > >> I guess you could start splitting the OpenWrt patches into a format > >> that makes them suitable for being merged upstream and starting with > >> the MIPS parts. There might be a bunch of checkpatch.pl cleanup work > >> to do before getting those submitted. > > > > I will do that if Jonathan does not have a working solution, which he > > would like to push upstream. So, let's wait for his reply. > > > > John, can you delay the merging of this patch for a few months, I will > try to prepare the necessary patches to add AR231x architecture to the > kernel and send them to linux-mips. OK -- looking forward to your patches.
On Thu, 2014-02-13 at 15:14 -0500, John W. Linville wrote: > On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote: > > John, can you delay the merging of this patch for a few months, I will > > try to prepare the necessary patches to add AR231x architecture to the > > kernel and send them to linux-mips. > > OK -- looking forward to your patches. So am I. Is there any news on this front? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014-04-15 21:08 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > On Thu, 2014-02-13 at 15:14 -0500, John W. Linville wrote: >> On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote: >> > John, can you delay the merging of this patch for a few months, I will >> > try to prepare the necessary patches to add AR231x architecture to the >> > kernel and send them to linux-mips. >> >> OK -- looking forward to your patches. > > So am I. Is there any news on this front? > Work still in progress :(
Jiri, Nick, Luis, John, On Wed, 2014-04-16 at 13:20 +0400, Sergey Ryazanov wrote: > 2014-04-15 21:08 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > > On Thu, 2014-02-13 at 15:14 -0500, John W. Linville wrote: > >> On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote: > >> > John, can you delay the merging of this patch for a few months, I will > >> > try to prepare the necessary patches to add AR231x architecture to the > >> > kernel and send them to linux-mips. > >> > >> OK -- looking forward to your patches. > > > > So am I. Is there any news on this front? > > > > Work still in progress :( ATHEROS_AR231X and the things depending on it, like AHB bus support, have been discussed for three years now. When will you (re)consider a patch to remove all currently dead code? And to state the obvious: AHB bus support, and the other code depending on ATHEROS_AR231X, can always be re-added once ATHEROS_AR231X gets added to the tree. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Paul, 2014-06-18 14:25 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > Jiri, Nick, Luis, John, > > On Wed, 2014-04-16 at 13:20 +0400, Sergey Ryazanov wrote: >> 2014-04-15 21:08 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: >> > On Thu, 2014-02-13 at 15:14 -0500, John W. Linville wrote: >> >> On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote: >> >> > John, can you delay the merging of this patch for a few months, I will >> >> > try to prepare the necessary patches to add AR231x architecture to the >> >> > kernel and send them to linux-mips. >> >> >> >> OK -- looking forward to your patches. >> > >> > So am I. Is there any news on this front? >> > >> >> Work still in progress :( > > ATHEROS_AR231X and the things depending on it, like AHB bus support, > have been discussed for three years now. When will you (re)consider a > patch to remove all currently dead code? > > And to state the obvious: AHB bus support, and the other code depending > on ATHEROS_AR231X, can always be re-added once ATHEROS_AR231X gets added > to the tree. > Work in progress, I don't stop it. Just work is progressing slower than I had planned. I am already cleanup the code (mostly checkpatch errors and warnings) and send patches to OpenWRT tree. Further I plan to simplify initialization and I will be ready to send patches upstream. I need a couple of weeks for this. Is its reasonable time to not make a mess of remove/add commits?
Hi Sergey, On Wed, 2014-06-18 at 15:10 +0400, Sergey Ryazanov wrote: > 2014-06-18 14:25 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > > ATHEROS_AR231X and the things depending on it, like AHB bus support, > > have been discussed for three years now. When will you (re)consider a > > patch to remove all currently dead code? > > > > And to state the obvious: AHB bus support, and the other code depending > > on ATHEROS_AR231X, can always be re-added once ATHEROS_AR231X gets added > > to the tree. > > Work in progress, I don't stop it. Just work is progressing slower > than I had planned. I am already cleanup the code (mostly checkpatch > errors and warnings) and send patches to OpenWRT tree. Further I plan > to simplify initialization and I will be ready to send patches > upstream. That's good to hear. > I need a couple of weeks for this. Is its reasonable time to not make > a mess of remove/add commits? Removing the code just to re-add it shortly after would indeed be awkward. Having this conversation every rc1 is getting a bit silly. Could Jiri e.a. perhaps set some specific deadline for ATHEROS_AR231X to be submitted? Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> Having this conversation every rc1 is getting a bit silly.
Hmm, wouldn't the obvious thing than to add the driver in it's current
form into staging? Is it well-separated from the rest of Atheros
WLAN drivers ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2014-06-18 at 15:15 +0200, Holger Schurig wrote: > Hmm, wouldn't the obvious thing than to add the driver in it's current > form into staging? Is it well-separated from the rest of Atheros > WLAN drivers ? A quick glance at the code shows an include of ar231x_platform.h (which doesn't exist) and uses of struct ar231x_board_config (ditto). So it won't build as is and therefor needs work to qualify for staging. Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jiri, Nick, Luis, John, On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > Having this conversation every rc1 is getting a bit silly. Could Jiri > e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > submitted? I waited until rc3. Have you seen any activity on this front? If not, should I resend the patch that removes the code in mainline that depends on ATHEROS_AR231X (ie, AHB bus support)? And to repeat the obvious: the removed code can always be re-added once ATHEROS_AR231X gets actually added to the tree. Thanks, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Paul, 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: > Jiri, Nick, Luis, John, > > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: >> Having this conversation every rc1 is getting a bit silly. Could Jiri >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be >> submitted? > > I waited until rc3. Have you seen any activity on this front? If not, > should I resend the patch that removes the code in mainline that depends > on ATHEROS_AR231X (ie, AHB bus support)? > Recent activity always could be found in [1]. Now I finish another one round of cleanups and have a plan to fix several things (you can always find something that you really want to improve). But if you insist I could immediately switch to "send upstream" mode. And seems that this would be better approach. 1. https://dev.openwrt.org/log/trunk/target/linux/atheros
Hi Sergey, On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: > > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > >> Having this conversation every rc1 is getting a bit silly. Could Jiri > >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > >> submitted? > > > > I waited until rc3. Have you seen any activity on this front? If not, > > should I resend the patch that removes the code in mainline that depends > > on ATHEROS_AR231X (ie, AHB bus support)? > > > Recent activity always could be found in [1]. Now I finish another one > round of cleanups and have a plan to fix several things (you can > always find something that you really want to improve). But if you > insist I could immediately switch to "send upstream" mode. And seems > that this would be better approach. > > 1. https://dev.openwrt.org/log/trunk/target/linux/atheros And where can the related PULL requests or patch submissions be found? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > Hi Sergey, > > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: >> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: >> >> Having this conversation every rc1 is getting a bit silly. Could Jiri >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be >> >> submitted? >> > >> > I waited until rc3. Have you seen any activity on this front? If not, >> > should I resend the patch that removes the code in mainline that depends >> > on ATHEROS_AR231X (ie, AHB bus support)? >> > >> Recent activity always could be found in [1]. Now I finish another one >> round of cleanups and have a plan to fix several things (you can >> always find something that you really want to improve). But if you >> insist I could immediately switch to "send upstream" mode. And seems >> that this would be better approach. >> >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > > And where can the related PULL requests or patch submissions be found? > I have not sent patches yet, since I thought that it would be easier to cleanup them in openwrt tree and then send them upstream.
On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > > Hi Sergey, > > > > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > >> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: > >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > >> >> Having this conversation every rc1 is getting a bit silly. Could Jiri > >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > >> >> submitted? > >> > > >> > I waited until rc3. Have you seen any activity on this front? If not, > >> > should I resend the patch that removes the code in mainline that depends > >> > on ATHEROS_AR231X (ie, AHB bus support)? > >> > > >> Recent activity always could be found in [1]. Now I finish another one > >> round of cleanups and have a plan to fix several things (you can > >> always find something that you really want to improve). But if you > >> insist I could immediately switch to "send upstream" mode. And seems > >> that this would be better approach. > >> > >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > > > > And where can the related PULL requests or patch submissions be found? > > > I have not sent patches yet, since I thought that it would be easier > to cleanup them in openwrt tree and then send them upstream. That excuse has worn a bit thin. Perhaps Paul should repost his removal and you can add a revert to the start of your patch series? John
2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>: > On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: >> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: >> > Hi Sergey, >> > >> > On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: >> >> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: >> >> > On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: >> >> >> Having this conversation every rc1 is getting a bit silly. Could >> >> >> Jiri >> >> >> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be >> >> >> submitted? >> >> > >> >> > I waited until rc3. Have you seen any activity on this front? If >> >> > not, >> >> > should I resend the patch that removes the code in mainline that >> >> > depends >> >> > on ATHEROS_AR231X (ie, AHB bus support)? >> >> > >> >> Recent activity always could be found in [1]. Now I finish another one >> >> round of cleanups and have a plan to fix several things (you can >> >> always find something that you really want to improve). But if you >> >> insist I could immediately switch to "send upstream" mode. And seems >> >> that this would be better approach. >> >> >> >> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros >> > >> > And where can the related PULL requests or patch submissions be found? >> > >> I have not sent patches yet, since I thought that it would be easier >> to cleanup them in openwrt tree and then send them upstream. > > That excuse has worn a bit thin. Perhaps Paul should repost his > removal and you can add a revert to the start of your patch series? > As for me, I do not like such flapping, but you have a final say in this discussion as a maintainer.
On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: > 2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>: >> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: >>> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: >>>> Hi Sergey, >>>> >>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: >>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: >>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: >>>>>>> Having this conversation every rc1 is getting a bit silly. Could >>>>>>> Jiri >>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be >>>>>>> submitted? >>>>>> >>>>>> I waited until rc3. Have you seen any activity on this front? If >>>>>> not, >>>>>> should I resend the patch that removes the code in mainline that >>>>>> depends >>>>>> on ATHEROS_AR231X (ie, AHB bus support)? >>>>>> >>>>> Recent activity always could be found in [1]. Now I finish another one >>>>> round of cleanups and have a plan to fix several things (you can >>>>> always find something that you really want to improve). But if you >>>>> insist I could immediately switch to "send upstream" mode. And seems >>>>> that this would be better approach. >>>>> >>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros >>>> >>>> And where can the related PULL requests or patch submissions be found? >>>> >>> I have not sent patches yet, since I thought that it would be easier >>> to cleanup them in openwrt tree and then send them upstream. >> >> That excuse has worn a bit thin. Perhaps Paul should repost his >> removal and you can add a revert to the start of your patch series? >> > As for me, I do not like such flapping Agreed in case what you have is in a good enough shape. You (and also others) can still clean up the code in upstream too. So, if it is mergeable, send it for upstream inclusion now, otherwise I am all for John to apply the Paul's patch. The unused code has been a way too long in the tree now. thanks,
2014-09-10 15:36 GMT+04:00, Jiri Slaby <jirislaby@gmail.com>: > On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: >> 2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>: >>> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: >>>> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: >>>>> Hi Sergey, >>>>> >>>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: >>>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: >>>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: >>>>>>>> Having this conversation every rc1 is getting a bit silly. Could >>>>>>>> Jiri >>>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be >>>>>>>> submitted? >>>>>>> >>>>>>> I waited until rc3. Have you seen any activity on this front? If >>>>>>> not, >>>>>>> should I resend the patch that removes the code in mainline that >>>>>>> depends >>>>>>> on ATHEROS_AR231X (ie, AHB bus support)? >>>>>>> >>>>>> Recent activity always could be found in [1]. Now I finish another >>>>>> one >>>>>> round of cleanups and have a plan to fix several things (you can >>>>>> always find something that you really want to improve). But if you >>>>>> insist I could immediately switch to "send upstream" mode. And seems >>>>>> that this would be better approach. >>>>>> >>>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros >>>>> >>>>> And where can the related PULL requests or patch submissions be found? >>>>> >>>> I have not sent patches yet, since I thought that it would be easier >>>> to cleanup them in openwrt tree and then send them upstream. >>> >>> That excuse has worn a bit thin. Perhaps Paul should repost his >>> removal and you can add a revert to the start of your patch series? >>> >> As for me, I do not like such flapping > > Agreed in case what you have is in a good enough shape. You (and also > others) can still clean up the code in upstream too. So, if it is > mergeable, send it for upstream inclusion now, otherwise I am all for > John to apply the Paul's patch. Two days is the last deadline :) > The unused code has been a way too long > in the tree now. Code actively used in owrt firmware and its forks.
On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: > 2014-09-10 15:36 GMT+04:00, Jiri Slaby <jirislaby@gmail.com>: > > On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: > >> 2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>: > >>> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > >>>> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > >>>>> Hi Sergey, > >>>>> > >>>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > >>>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: > >>>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > >>>>>>>> Having this conversation every rc1 is getting a bit silly. Could > >>>>>>>> Jiri > >>>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > >>>>>>>> submitted? > >>>>>>> > >>>>>>> I waited until rc3. Have you seen any activity on this front? If > >>>>>>> not, > >>>>>>> should I resend the patch that removes the code in mainline that > >>>>>>> depends > >>>>>>> on ATHEROS_AR231X (ie, AHB bus support)? > >>>>>>> > >>>>>> Recent activity always could be found in [1]. Now I finish another > >>>>>> one > >>>>>> round of cleanups and have a plan to fix several things (you can > >>>>>> always find something that you really want to improve). But if you > >>>>>> insist I could immediately switch to "send upstream" mode. And seems > >>>>>> that this would be better approach. > >>>>>> > >>>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > >>>>> > >>>>> And where can the related PULL requests or patch submissions be found? > >>>>> > >>>> I have not sent patches yet, since I thought that it would be easier > >>>> to cleanup them in openwrt tree and then send them upstream. > >>> > >>> That excuse has worn a bit thin. Perhaps Paul should repost his > >>> removal and you can add a revert to the start of your patch series? > >>> > >> As for me, I do not like such flapping > > > > Agreed in case what you have is in a good enough shape. You (and also > > others) can still clean up the code in upstream too. So, if it is > > mergeable, send it for upstream inclusion now, otherwise I am all for > > John to apply the Paul's patch. > > Two days is the last deadline :) > > > The unused code has been a way too long > > in the tree now. > > Code actively used in owrt firmware and its forks. Is this code coming or not? When can I expect to see it posted?
On Thu, Sep 11, 2014 at 03:21:46PM -0400, John W. Linville wrote: > On Wed, Sep 10, 2014 at 04:19:21PM +0400, Sergey Ryazanov wrote: > > 2014-09-10 15:36 GMT+04:00, Jiri Slaby <jirislaby@gmail.com>: > > > On 09/10/2014, 12:33 PM, Sergey Ryazanov wrote: > > >> 2014-09-09 22:27 GMT+04:00, John W. Linville <linville@tuxdriver.com>: > > >>> On Fri, Sep 05, 2014 at 04:02:10PM +0400, Sergey Ryazanov wrote: > > >>>> 2014-09-05 15:33 GMT+04:00 Paul Bolle <pebolle@tiscali.nl>: > > >>>>> Hi Sergey, > > >>>>> > > >>>>> On Fri, 2014-09-05 at 15:12 +0400, Sergey Ryazanov wrote: > > >>>>>> 2014-09-05 14:10 GMT+04:00, Paul Bolle <pebolle@tiscali.nl>: > > >>>>>>> On Wed, 2014-06-18 at 13:46 +0200, Paul Bolle wrote: > > >>>>>>>> Having this conversation every rc1 is getting a bit silly. Could > > >>>>>>>> Jiri > > >>>>>>>> e.a. perhaps set some specific deadline for ATHEROS_AR231X to be > > >>>>>>>> submitted? > > >>>>>>> > > >>>>>>> I waited until rc3. Have you seen any activity on this front? If > > >>>>>>> not, > > >>>>>>> should I resend the patch that removes the code in mainline that > > >>>>>>> depends > > >>>>>>> on ATHEROS_AR231X (ie, AHB bus support)? > > >>>>>>> > > >>>>>> Recent activity always could be found in [1]. Now I finish another > > >>>>>> one > > >>>>>> round of cleanups and have a plan to fix several things (you can > > >>>>>> always find something that you really want to improve). But if you > > >>>>>> insist I could immediately switch to "send upstream" mode. And seems > > >>>>>> that this would be better approach. > > >>>>>> > > >>>>>> 1. https://dev.openwrt.org/log/trunk/target/linux/atheros > > >>>>> > > >>>>> And where can the related PULL requests or patch submissions be found? > > >>>>> > > >>>> I have not sent patches yet, since I thought that it would be easier > > >>>> to cleanup them in openwrt tree and then send them upstream. > > >>> > > >>> That excuse has worn a bit thin. Perhaps Paul should repost his > > >>> removal and you can add a revert to the start of your patch series? > > >>> > > >> As for me, I do not like such flapping > > > > > > Agreed in case what you have is in a good enough shape. You (and also > > > others) can still clean up the code in upstream too. So, if it is > > > mergeable, send it for upstream inclusion now, otherwise I am all for > > > John to apply the Paul's patch. > > > > Two days is the last deadline :) > > > > > The unused code has been a way too long > > > in the tree now. > > > > Code actively used in owrt firmware and its forks. > > Is this code coming or not? When can I expect to see it posted? FYI -- Sergey posted a series to linux-mips on 14 September 2014 that touches the symbol in question. For whatever reason, it is posted there as RFC. Does this satisfy the interested parties?? John
On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote: > FYI -- Sergey posted a series to linux-mips on 14 September 2014 that > touches the symbol in question. For whatever reason, it is posted > there as RFC. Thanks for passing that on. > Does this satisfy the interested parties?? In case I qualify as an interested party: resolving this by, in short, making AHB support actually buildable is of course the preferable solution. Whether or not we should drop my patch while waiting for that series to land in linux-next is not my call. But if it hasn't landed by, say, about the time v3.18-rc3 is released I might raise this issue again. I must say that I'm a bit puzzled why people have resisted this rather small cleanup for years. How did having unbuildable AHB support in mainline benefit anyone? Couldn't the revert of this cleanup also be handled out of tree? Note that the revert is only "6 files changed, 3 insertions(+), 294 deletions(-)", while the series is "39 files changed, 3911 insertions(+), 10 deletions(-)". Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Sep 16, 2014 at 10:26:59PM +0200, Paul Bolle wrote: > On Mon, 2014-09-15 at 14:45 -0400, John W. Linville wrote: > > FYI -- Sergey posted a series to linux-mips on 14 September 2014 that > > touches the symbol in question. For whatever reason, it is posted > > there as RFC. > > Thanks for passing that on. > > > Does this satisfy the interested parties?? > > In case I qualify as an interested party: resolving this by, in short, > making AHB support actually buildable is of course the preferable > solution. > > Whether or not we should drop my patch while waiting for that series to > land in linux-next is not my call. But if it hasn't landed by, say, > about the time v3.18-rc3 is released I might raise this issue again. > > I must say that I'm a bit puzzled why people have resisted this rather > small cleanup for years. How did having unbuildable AHB support in > mainline benefit anyone? Couldn't the revert of this cleanup also be > handled out of tree? Note that the revert is only "6 files changed, 3 > insertions(+), 294 deletions(-)", while the series is "39 files changed, > 3911 insertions(+), 10 deletions(-)". I think it got added with the notion that the code was "coming soon". As you have tried to remove it, the "coming soon" refrain continued. I'm still inclined to merge your patch. An RFC series posted to another mailing list doesn't really change my mind. John
diff --git a/drivers/net/wireless/ath/ath5k/Kconfig b/drivers/net/wireless/ath/ath5k/Kconfig index c9f81a3..3bc0d57 100644 --- a/drivers/net/wireless/ath/ath5k/Kconfig +++ b/drivers/net/wireless/ath/ath5k/Kconfig @@ -1,13 +1,13 @@ config ATH5K tristate "Atheros 5xxx wireless cards support" - depends on (PCI || ATHEROS_AR231X) && MAC80211 + depends on PCI && MAC80211 select ATH_COMMON select MAC80211_LEDS select LEDS_CLASS select NEW_LEDS select AVERAGE - select ATH5K_AHB if (ATHEROS_AR231X && !PCI) - select ATH5K_PCI if (!ATHEROS_AR231X && PCI) + select ATH5K_AHB if !PCI + select ATH5K_PCI if PCI ---help--- This module adds support for wireless adapters based on Atheros 5xxx chipset. @@ -54,14 +54,14 @@ config ATH5K_TRACER config ATH5K_AHB bool "Atheros 5xxx AHB bus support" - depends on (ATHEROS_AR231X && !PCI) + depends on !PCI ---help--- This adds support for WiSoC type chipsets of the 5xxx Atheros family. config ATH5K_PCI bool "Atheros 5xxx PCI bus support" - depends on (!ATHEROS_AR231X && PCI) + depends on PCI ---help--- This adds support for PCI type chipsets of the 5xxx Atheros family. diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h index 74bd54d..5f2843c 100644 --- a/drivers/net/wireless/ath/ath5k/ath5k.h +++ b/drivers/net/wireless/ath/ath5k/ath5k.h @@ -1646,32 +1646,6 @@ static inline struct ath_regulatory *ath5k_hw_regulatory(struct ath5k_hw *ah) return &(ath5k_hw_common(ah)->regulatory); } -#ifdef CONFIG_ATHEROS_AR231X -#define AR5K_AR2315_PCI_BASE ((void __iomem *)0xb0100000) - -static inline void __iomem *ath5k_ahb_reg(struct ath5k_hw *ah, u16 reg) -{ - /* On AR2315 and AR2317 the PCI clock domain registers - * are outside of the WMAC register space */ - if (unlikely((reg >= 0x4000) && (reg < 0x5000) && - (ah->ah_mac_srev >= AR5K_SREV_AR2315_R6))) - return AR5K_AR2315_PCI_BASE + reg; - - return ah->iobase + reg; -} - -static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg) -{ - return ioread32(ath5k_ahb_reg(ah, reg)); -} - -static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg) -{ - iowrite32(val, ath5k_ahb_reg(ah, reg)); -} - -#else - static inline u32 ath5k_hw_reg_read(struct ath5k_hw *ah, u16 reg) { return ioread32(ah->iobase + reg); @@ -1682,8 +1656,6 @@ static inline void ath5k_hw_reg_write(struct ath5k_hw *ah, u32 val, u16 reg) iowrite32(val, ah->iobase + reg); } -#endif - static inline enum ath_bus_type ath5k_get_bus_type(struct ath5k_hw *ah) { return ath5k_hw_common(ah)->bus_ops->ath_bus_type; diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c index ef35da8..d43e546 100644 --- a/drivers/net/wireless/ath/ath5k/base.c +++ b/drivers/net/wireless/ath/ath5k/base.c @@ -99,15 +99,6 @@ static int ath5k_reset(struct ath5k_hw *ah, struct ieee80211_channel *chan, /* Known SREVs */ static const struct ath5k_srev_name srev_names[] = { -#ifdef CONFIG_ATHEROS_AR231X - { "5312", AR5K_VERSION_MAC, AR5K_SREV_AR5312_R2 }, - { "5312", AR5K_VERSION_MAC, AR5K_SREV_AR5312_R7 }, - { "2313", AR5K_VERSION_MAC, AR5K_SREV_AR2313_R8 }, - { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R6 }, - { "2315", AR5K_VERSION_MAC, AR5K_SREV_AR2315_R7 }, - { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R1 }, - { "2317", AR5K_VERSION_MAC, AR5K_SREV_AR2317_R2 }, -#else { "5210", AR5K_VERSION_MAC, AR5K_SREV_AR5210 }, { "5311", AR5K_VERSION_MAC, AR5K_SREV_AR5311 }, { "5311A", AR5K_VERSION_MAC, AR5K_SREV_AR5311A }, @@ -126,7 +117,6 @@ static const struct ath5k_srev_name srev_names[] = { { "5418", AR5K_VERSION_MAC, AR5K_SREV_AR5418 }, { "2425", AR5K_VERSION_MAC, AR5K_SREV_AR2425 }, { "2417", AR5K_VERSION_MAC, AR5K_SREV_AR2417 }, -#endif { "xxxxx", AR5K_VERSION_MAC, AR5K_SREV_UNKNOWN }, { "5110", AR5K_VERSION_RAD, AR5K_SREV_RAD_5110 }, { "5111", AR5K_VERSION_RAD, AR5K_SREV_RAD_5111 }, @@ -142,10 +132,6 @@ static const struct ath5k_srev_name srev_names[] = { { "5413", AR5K_VERSION_RAD, AR5K_SREV_RAD_5413 }, { "5424", AR5K_VERSION_RAD, AR5K_SREV_RAD_5424 }, { "5133", AR5K_VERSION_RAD, AR5K_SREV_RAD_5133 }, -#ifdef CONFIG_ATHEROS_AR231X - { "2316", AR5K_VERSION_RAD, AR5K_SREV_RAD_2316 }, - { "2317", AR5K_VERSION_RAD, AR5K_SREV_RAD_2317 }, -#endif { "xxxxx", AR5K_VERSION_RAD, AR5K_SREV_UNKNOWN }, }; diff --git a/drivers/net/wireless/ath/ath5k/led.c b/drivers/net/wireless/ath/ath5k/led.c index f77ef36..c36a98f 100644 --- a/drivers/net/wireless/ath/ath5k/led.c +++ b/drivers/net/wireless/ath/ath5k/led.c @@ -162,20 +162,13 @@ int ath5k_init_leds(struct ath5k_hw *ah) { int ret = 0; struct ieee80211_hw *hw = ah->hw; -#ifndef CONFIG_ATHEROS_AR231X - struct pci_dev *pdev = ah->pdev; -#endif char name[ATH5K_LED_MAX_NAME_LEN + 1]; const struct pci_device_id *match; if (!ah->pdev) return 0; -#ifdef CONFIG_ATHEROS_AR231X - match = NULL; -#else match = pci_match_id(&ath5k_led_devices[0], pdev); -#endif if (match) { __set_bit(ATH_STAT_LEDSOFT, ah->status); ah->led_pin = ATH_PIN(match->driver_data);
The symbol is an orphan, get rid of it. Signed-off-by: Richard Weinberger <richard@nod.at> --- drivers/net/wireless/ath/ath5k/Kconfig | 10 +++++----- drivers/net/wireless/ath/ath5k/ath5k.h | 28 ---------------------------- drivers/net/wireless/ath/ath5k/base.c | 14 -------------- drivers/net/wireless/ath/ath5k/led.c | 7 ------- 4 files changed, 5 insertions(+), 54 deletions(-)