Remove orphan kconfig symbols

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

---
 drivers/usb/phy/Kconfig      | 1 -
 drivers/video/mmp/Kconfig    | 2 +-
 drivers/video/mmp/hw/Kconfig | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

drivers/usb/phy/Kconfig +0 -0

index 7d1451d..b9b1c52 100644

Quoted 16 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

---
 drivers/usb/phy/Kconfig      | 1 -
 drivers/video/mmp/Kconfig    | 2 +-
 drivers/video/mmp/hw/Kconfig | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

drivers/usb/phy/Kconfig +0 -0

index 7d1451d..b9b1c52 100644

drivers/usb/phy/Kconfig config KEYSTONE_USB_PHY · line 66

Quoted 7 lines

drivers/usb/phy/Kconfig +0 -1

@@ -61,7 +61,6 @@ config KEYSTONE_USB_PHY
 
 config MV_U3D_PHY
 	bool "Marvell USB 3.0 PHY controller Driver"
-	depends on CPU_MMP3
 	select USB_PHY
 	help
 	  Enable this to support Marvell USB 3.0 phy controller for Marvell

Do this and the driver breaks the build so it needs to depend on something:

drivers/usb/phy/phy-mv-u3d-usb.c: In function ‘mv_u3d_phy_read’:
drivers/usb/phy/phy-mv-u3d-usb.c:42:2: error: implicit declaration of function ‘writel_relaxed’ [-Werror=implicit-function-declaration]

Sorry, I can't take this as-is.

Quoted 28 lines · Greg Kroah-Hartman

Quoted 16 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

---
 drivers/usb/phy/Kconfig      | 1 -
 drivers/video/mmp/Kconfig    | 2 +-
 drivers/video/mmp/hw/Kconfig | 2 +-
 3 files changed, 2 insertions(+), 3 deletions(-)

drivers/usb/phy/Kconfig +0 -0

index 7d1451d..b9b1c52 100644

drivers/usb/phy/Kconfig config KEYSTONE_USB_PHY · line 66

Quoted 7 lines

drivers/usb/phy/Kconfig +0 -1

@@ -61,7 +61,6 @@ config KEYSTONE_USB_PHY
 
 config MV_U3D_PHY
    bool "Marvell USB 3.0 PHY controller Driver"
-   depends on CPU_MMP3
    select USB_PHY
    help
      Enable this to support Marvell USB 3.0 phy controller for Marvell

Do this and the driver breaks the build so it needs to depend on something:

Quoted 2 lines

drivers/usb/phy/phy-mv-u3d-usb.c: In function ‘mv_u3d_phy_read’:
drivers/usb/phy/phy-mv-u3d-usb.c:42:2: error: implicit declaration of function ‘writel_relaxed’ [-Werror=implicit-function-declaration]

This sort of proves that a driver that depends on an unknown Kconfig symbol gets no build coverage (and will bit rot).

Quoted 1 line

Sorry, I can't take this as-is.

My mistake, I should have spotted this when looking a Richard's patch.

Some background (which I quickly dug up): config MV_U3D_PHY got added in v3.7 through commit a67e76ac904c ("usb: phy: mv_u3d: Add usb phy driver for mv_u3d"). It then depended on USB_MV_U3D. And that symbol depended on CPU_MMP3 at that time. Ie, MV_U3D_PHY was unbuildable when it was added.

In commit 60630c2eabd4 ("usb: gadget: mv_u3d: drop ARCH dependency") MV_U3D_PHY was made depended directly on CPU_MMP3. That kept it unbuildable, of course.

Richard, assuming you agree with the above short history of MV_U3D_PHY, would you mind sending a v2 that removes this unbuildable driver?

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/i2c/busses/Kconfig +0 -0

index f5ed031..de17c55 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <richard-/[email protected]>

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/dma/Kconfig +0 -0

index 9bed1a2..e4382ec 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <richard-/[email protected]>

---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iommu/Kconfig +0 -0

index 79bbc21..20d062d 100644

Quoted 13 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/iommu/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/iommu/Kconfig +0 -0

index 79bbc21..20d062d 100644
@@ -178,7 +178,7 @@ config TEGRA_IOMMU_SMMU
 

drivers/iommu/Kconfig config TEGRA_IOMMU_SMMU · line 184

Quoted 7 lines

drivers/iommu/Kconfig +1 -1

 config EXYNOS_IOMMU
      bool "Exynos IOMMU Support"
-     depends on ARCH_EXYNOS && EXYNOS_DEV_SYSMMU
+     depends on ARCH_EXYNOS
      select IOMMU_API
      help
        Support for the IOMMU(System MMU) of Samsung Exynos application

I noted this one about a year ago (see
https://lkml.org/lkml/2013/3/5/401 ). By now I wonder whether EXYNOS_IOMMU (and everything depending on it) shouldn't be removed. That code has been unbuildable for at least a year now (I have not checked how much code is involved).

+cc linux-samsung-soc list

Quoted 5 lines · Paul Bolle

I noted this one about a year ago (see
https://lkml.org/lkml/2013/3/5/401 ). By now I wonder whether EXYNOS_IOMMU (and everything depending on it) shouldn't be removed. That code has been unbuildable for at least a year now (I have not checked how much code is involved).

Please refer to some on-going discussion about it at [1].

[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/26842

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 crypto/asymmetric_keys/Kconfig | 1 -
 1 file changed, 1 deletion(-)

crypto/asymmetric_keys/Kconfig +0 -0

index 03a6eb9..0320c7d 100644

Quoted 3 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

Quoted 10 lines

---
 crypto/asymmetric_keys/Kconfig | 1 -
 1 file changed, 1 deletion(-)

crypto/asymmetric_keys/Kconfig +0 -0

index 03a6eb9..0320c7d 100644
@@ -22,7 +22,6 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
 

crypto/asymmetric_keys/Kconfig config ASYMMETRIC_PUBLIC_KEY_SUBTYPE · line 27

Quoted 6 lines

crypto/asymmetric_keys/Kconfig +0 -1

 config PUBLIC_KEY_ALGO_RSA
 	tristate "RSA public-key algorithm"
-	select MPILIB_EXTRA
 	select MPILIB
 	help
 	  This option enables support for the RSA algorithm (PKCS#1, RFC3447).

I tried this a year ago (see https://lkml.org/lkml/2013/3/8/142 ).

Quoted 17 lines · Paul Bolle

Quoted 3 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

Quoted 10 lines

---
 crypto/asymmetric_keys/Kconfig | 1 -
 1 file changed, 1 deletion(-)

crypto/asymmetric_keys/Kconfig +0 -0

index 03a6eb9..0320c7d 100644
@@ -22,7 +22,6 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
 

Quoted 8 lines

crypto/asymmetric_keys/Kconfig config ASYMMETRIC_PUBLIC_KEY_SUBTYPE · line 27

Quoted 6 lines

crypto/asymmetric_keys/Kconfig +0 -1

 config PUBLIC_KEY_ALGO_RSA
 	tristate "RSA public-key algorithm"
-	select MPILIB_EXTRA
 	select MPILIB
 	help
 	  This option enables support for the RSA algorithm (PKCS#1, RFC3447).

I tried this a year ago (see https://lkml.org/lkml/2013/3/8/142 ).

Did anyone else ever find some time to look at this oneliner?

Quoted 27 lines · Paul Bolle

Quoted 25 lines · Paul Bolle

Quoted 3 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by Paul Bolle <[email protected]>

Quoted 9 lines

---
 crypto/asymmetric_keys/Kconfig | 1 -
 1 file changed, 1 deletion(-)

crypto/asymmetric_keys/Kconfig +0 -0

index 03a6eb9..0320c7d 100644

crypto/asymmetric_keys/Kconfig config ASYMMETRIC_PUBLIC_KEY_SUBTYPE · line 27

Quoted 7 lines

crypto/asymmetric_keys/Kconfig +0 -1

@@ -22,7 +22,6 @@ config ASYMMETRIC_PUBLIC_KEY_SUBTYPE
 
 config PUBLIC_KEY_ALGO_RSA
 	tristate "RSA public-key algorithm"
-	select MPILIB_EXTRA
 	select MPILIB
 	help
 	  This option enables support for the RSA algorithm (PKCS#1, RFC3447).

I tried this a year ago (see https://lkml.org/lkml/2013/3/8/142 ).

Quoted 1 line

Did anyone else ever find some time to look at this oneliner?

Last time I asked about that part of the tree, Herbert said it should go through James Morris' tree. CCed.

http://lkml.kernel.org/r/[email protected]

Unless akpm picks it up first. Also CCed.

This oneliner is neither part of v3.16-rc1 nor part of linux-next. It applies cleanly to next-20140618. Should I hope that Jiri Kosina wants to take it for trivial (CC-ed)?

Quoted 3 lines

This oneliner is neither part of v3.16-rc1 nor part of linux-next. It applies cleanly to next-20140618. Should I hope that Jiri Kosina wants to take it for trivial (CC-ed)?

Yeah, he will.

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/char/hw_random/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/char/hw_random/Kconfig +0 -0

index 2f2b084..eab6056 100644

The driver for the "Picochip picoXcell true random number generator" was added in v2.6.39. Its Kconfig symbol has always depended on PICOXCELL_PC3X3. But that Kconfig symbol has never been part of the tree. This means this driver has never been buildable. Let's remove it. It can be re-added if its dependencies are actually part of the tree.

Signed-off-by Paul Bolle <[email protected]>

Hi Paul,

Quoted 6 lines · Paul Bolle

The driver for the "Picochip picoXcell true random number generator" was added in v2.6.39. Its Kconfig symbol has always depended on PICOXCELL_PC3X3. But that Kconfig symbol has never been part of the tree. This means this driver has never been buildable. Let's remove it. It can be re-added if its dependencies are actually part of the tree.

Quoted 1 line

Signed-off-by Paul Bolle <[email protected]>

I wish I had the bandwidth to get this properly supported, but this seems sensible to me.

Acked-by Jamie Iles <[email protected]>

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

 drivers/video/mmp/Kconfig       |  2 +-
 drivers/video/mmp/hw/Kconfig    |  2 +-
 drivers/video/mmp/hw/mmp_ctrl.h | 32 --------------------------------
 3 files changed, 2 insertions(+), 34 deletions(-)

[..]

drivers/video/mmp/hw/Kconfig +0 -0

index 57b03e2..95e8ec2 100644

Am 09.02.2014 23:24, schrieb Paul Bolle:

Quoted 3 lines · Richard Weinberger

Quoted 2 lines

The symbol is an orphan, get rid of it.

Quoted 5 lines

Quoted 1 line

Signed-off-by Richard Weinberger <[email protected]>

This one first entered the tree in v3.9, with commit 59393bb94c10 ("video: mmp display subsystem"). The Kconfig symbol has not yet been added.

Thanks a lot for digging out the background info!
I'll add them to the commit message.

Richard,

Quoted 10 lines · Richard Weinberger

Am 09.02.2014 23:24, schrieb Paul Bolle:

Quoted 8 lines · Richard Weinberger

Quoted 3 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

This one first entered the tree in v3.9, with commit 59393bb94c10 ("video: mmp display subsystem"). The Kconfig symbol has not yet been added.

Quoted 2 lines

Thanks a lot for digging out the background info!
I'll add them to the commit message.

Did you ever find the time to update the commit message? If not, should I submit an updated version of this patch?

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

The symbol is an orphan, get rid of it.

Quoted 1 line · Richard Weinberger

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.

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <richard-/[email protected]>

---
 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(-)

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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.

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 3 lines

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.

2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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:

Quoted 21 lines

2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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.

Quoted 7 lines

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 <[email protected]>:

Quoted 30 lines

Am 10.02.2014 13:05, schrieb Sergey Ryazanov:

Quoted 28 lines

2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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

Quoted 6 lines

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.

Quoted 4 lines

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 <[email protected]>:

Quoted 31 lines

2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:

Quoted 30 lines

Am 10.02.2014 13:05, schrieb Sergey Ryazanov:

Quoted 28 lines

2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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

Quoted 7 lines

Quoted 6 lines

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...

Quoted 4 lines

Quoted 4 lines

I hope Jonathan do kernel part. If not, i can provide some work, since i have testing boards and expiriance on this hardware.

Quoted 2 lines

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 <[email protected]>:

Quoted 53 lines

2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:

Quoted 31 lines

2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:

Quoted 30 lines

Am 10.02.2014 13:05, schrieb Sergey Ryazanov:

Quoted 28 lines

2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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

Quoted 7 lines

Quoted 6 lines

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...

Quoted 6 lines

Quoted 4 lines

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.

Quoted 4 lines

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 <[email protected]>:

Quoted 59 lines

2014-02-11 2:37 GMT+04:00 Florian Fainelli <[email protected]>:

Quoted 57 lines

2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:

Quoted 31 lines

2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:

Quoted 30 lines

Am 10.02.2014 13:05, schrieb Sergey Ryazanov:

Quoted 28 lines

2014-02-10 0:03 GMT+04:00 Richard Weinberger <richard-/[email protected]>:

Quoted 13 lines

Am 09.02.2014 20:18, schrieb Hauke Mehrtens:

Quoted 12 lines · Richard Weinberger

Quoted 10 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <richard-/[email protected]>

---
 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(-)

Quoted 6 lines

Quoted 3 lines

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

Quoted 7 lines

Quoted 6 lines

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...

Quoted 6 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 3 lines · Sergey Ryazanov

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.

Quoted 6 lines · Sergey Ryazanov

Quoted 3 lines

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?

2014-04-15 21:08 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 6 lines · John W. Linville

Quoted 5 lines · Sergey Ryazanov

Quoted 3 lines

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.

Quoted 4 lines

Quoted 1 line

OK -- looking forward to your patches.

So am I. Is there any news on this front?

Work still in progress :(

Jiri, Nick, Luis, John,

Quoted 7 lines · Sergey Ryazanov

2014-04-15 21:08 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 6 lines · John W. Linville

Quoted 5 lines · Sergey Ryazanov

Quoted 3 lines

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.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

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.

2014-06-18 14:25 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 7 lines

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?

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 ?

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?

Jiri, Nick, Luis, John,

Quoted 3 lines · Paul Bolle

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)?

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 9 lines · Paul Bolle

Quoted 3 lines

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,

Quoted 16 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 9 lines · Paul Bolle

Quoted 3 lines

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.

Quoted 1 line

1. https://dev.openwrt.org/log/trunk/target/linux/atheros

And where can the related PULL requests or patch submissions be found?

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 19 lines

Hi Sergey,

Quoted 16 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 9 lines · Paul Bolle

Quoted 3 lines

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.

Quoted 4 lines

Quoted 1 line

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.

AHB bus support was added in v2.6.38, through commit a0b907ee2a71 ("ath5k: Add AHB bus support."). That code can only be build if the Kconfig symbol ATHEROS_AR231X is set. But that symbol has never been added to the tree. So AHB bus support has always been dead code.

Let's remove all code that depends on ATHEROS_AR231X. If that symbol ever gets added to the tree the AHB bus support can be re-added too.

Signed-off-by Paul Bolle <[email protected]>

---
First sent in https://lkml.org/lkml/2013/5/13/303 . Updated on top of next-20140909.

Build tested only (no access to this hardware).

 drivers/net/wireless/ath/ath5k/Kconfig  |  14 +-
 drivers/net/wireless/ath/ath5k/Makefile |   1 -
 drivers/net/wireless/ath/ath5k/ahb.c    | 234 --------------------------------
 drivers/net/wireless/ath/ath5k/ath5k.h  |  28 ----
 drivers/net/wireless/ath/ath5k/base.c   |  14 --
 drivers/net/wireless/ath/ath5k/led.c    |   6 -
 6 files changed, 3 insertions(+), 294 deletions(-)
 delete mode 100644 drivers/net/wireless/ath/ath5k/ahb.c

drivers/net/wireless/ath/ath5k/Kconfig +3 -11

index c9f81a388f15..93caf8e68901 100644
@@ -1,13 +1,12 @@
 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_PCI
 	---help---
 	  This module adds support for wireless adapters based on
 	  Atheros 5xxx chipset.

@@ -52,16 +51,9 @@ config ATH5K_TRACER
 
 	  If unsure, say N.
 
-config ATH5K_AHB
-	bool "Atheros 5xxx AHB bus support"
-	depends on (ATHEROS_AR231X && !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.

drivers/net/wireless/ath/ath5k/Makefile +0 -1

index 1b3a34f7f224..51e2d8668041 100644
@@ -17,6 +17,5 @@ ath5k-y				+= ani.o
 ath5k-y				+= sysfs.o
 ath5k-y				+= mac80211-ops.o
 ath5k-$(CONFIG_ATH5K_DEBUG)	+= debug.o
-ath5k-$(CONFIG_ATH5K_AHB)	+= ahb.o
 ath5k-$(CONFIG_ATH5K_PCI)	+= pci.o
 obj-$(CONFIG_ATH5K)		+= ath5k.o

drivers/net/wireless/ath/ath5k/ahb.c deleted +0 -234

deleted file mode 100644
index 79bffe165cab..000000000000
@@ -1,234 +0,0 @@
-/*
- * Copyright (c) 2008-2009 Atheros Communications Inc.
- * Copyright (c) 2009 Gabor Juhos <[email protected]>
- * Copyright (c) 2009 Imre Kaloz <[email protected]>
- *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-#include <linux/nl80211.h>
-#include <linux/platform_device.h>
-#include <linux/etherdevice.h>
-#include <linux/export.h>
-#include <ar231x_platform.h>
-#include "ath5k.h"
-#include "debug.h"
-#include "base.h"
-#include "reg.h"
-
-/* return bus cachesize in 4B word units */
-static void ath5k_ahb_read_cachesize(struct ath_common *common, int *csz)
-{
-	*csz = L1_CACHE_BYTES >> 2;
-}
-
-static bool
-ath5k_ahb_eeprom_read(struct ath_common *common, u32 off, u16 *data)
-{
-	struct ath5k_hw *ah = common->priv;
-	struct platform_device *pdev = to_platform_device(ah->dev);
-	struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
-	u16 *eeprom, *eeprom_end;
-
-	eeprom = (u16 *) bcfg->radio;
-	eeprom_end = ((void *) bcfg->config) + BOARD_CONFIG_BUFSZ;
-
-	eeprom += off;
-	if (eeprom > eeprom_end)
-		return false;
-
-	*data = *eeprom;
-	return true;
-}
-
-int ath5k_hw_read_srev(struct ath5k_hw *ah)
-{
-	struct platform_device *pdev = to_platform_device(ah->dev);
-	struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
-	ah->ah_mac_srev = bcfg->devid;
-	return 0;
-}
-
-static int ath5k_ahb_eeprom_read_mac(struct ath5k_hw *ah, u8 *mac)
-{
-	struct platform_device *pdev = to_platform_device(ah->dev);
-	struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
-	u8 *cfg_mac;
-
-	if (to_platform_device(ah->dev)->id == 0)
-		cfg_mac = bcfg->config->wlan0_mac;
-	else
-		cfg_mac = bcfg->config->wlan1_mac;
-
-	memcpy(mac, cfg_mac, ETH_ALEN);
-	return 0;
-}
-
-static const struct ath_bus_ops ath_ahb_bus_ops = {
-	.ath_bus_type = ATH_AHB,
-	.read_cachesize = ath5k_ahb_read_cachesize,
-	.eeprom_read = ath5k_ahb_eeprom_read,
-	.eeprom_read_mac = ath5k_ahb_eeprom_read_mac,
-};
-
-/*Initialization*/
-static int ath_ahb_probe(struct platform_device *pdev)
-{
-	struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
-	struct ath5k_hw *ah;
-	struct ieee80211_hw *hw;
-	struct resource *res;
-	void __iomem *mem;
-	int irq;
-	int ret = 0;
-	u32 reg;
-
-	if (!dev_get_platdata(&pdev->dev)) {
-		dev_err(&pdev->dev, "no platform data specified\n");
-		ret = -EINVAL;
-		goto err_out;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "no memory resource found\n");
-		ret = -ENXIO;
-		goto err_out;
-	}
-
-	mem = ioremap_nocache(res->start, resource_size(res));
-	if (mem == NULL) {
-		dev_err(&pdev->dev, "ioremap failed\n");
-		ret = -ENOMEM;
-		goto err_out;
-	}
-
-	res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-	if (res == NULL) {
-		dev_err(&pdev->dev, "no IRQ resource found\n");
-		ret = -ENXIO;
-		goto err_iounmap;
-	}
-
-	irq = res->start;
-
-	hw = ieee80211_alloc_hw(sizeof(struct ath5k_hw), &ath5k_hw_ops);
-	if (hw == NULL) {
-		dev_err(&pdev->dev, "no memory for ieee80211_hw\n");
-		ret = -ENOMEM;
-		goto err_iounmap;
-	}
-
-	ah = hw->priv;
-	ah->hw = hw;
-	ah->dev = &pdev->dev;
-	ah->iobase = mem;
-	ah->irq = irq;
-	ah->devid = bcfg->devid;
-
-	if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
-		/* Enable WMAC AHB arbitration */
-		reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
-		reg |= AR5K_AR2315_AHB_ARB_CTL_WLAN;
-		iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
-
-		/* Enable global WMAC swapping */
-		reg = ioread32((void __iomem *) AR5K_AR2315_BYTESWAP);
-		reg |= AR5K_AR2315_BYTESWAP_WMAC;
-		iowrite32(reg, (void __iomem *) AR5K_AR2315_BYTESWAP);
-	} else {
-		/* Enable WMAC DMA access (assuming 5312 or 231x*/
-		/* TODO: check other platforms */
-		reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
-		if (to_platform_device(ah->dev)->id == 0)
-			reg |= AR5K_AR5312_ENABLE_WLAN0;
-		else
-			reg |= AR5K_AR5312_ENABLE_WLAN1;
-		iowrite32(reg, (void __iomem *) AR5K_AR5312_ENABLE);
-
-		/*
-		 * On a dual-band AR5312, the multiband radio is only
-		 * used as pass-through. Disable 2 GHz support in the
-		 * driver for it
-		 */
-		if (to_platform_device(ah->dev)->id == 0 &&
-		    (bcfg->config->flags & (BD_WLAN0 | BD_WLAN1)) ==
-		     (BD_WLAN1 | BD_WLAN0))
-			ah->ah_capabilities.cap_needs_2GHz_ovr = true;
-		else
-			ah->ah_capabilities.cap_needs_2GHz_ovr = false;
-	}
-
-	ret = ath5k_init_ah(ah, &ath_ahb_bus_ops);
-	if (ret != 0) {
-		dev_err(&pdev->dev, "failed to attach device, err=%d\n", ret);
-		ret = -ENODEV;
-		goto err_free_hw;
-	}
-
-	platform_set_drvdata(pdev, hw);
-
-	return 0;
-
- err_free_hw:
-	ieee80211_free_hw(hw);
- err_iounmap:
-        iounmap(mem);
- err_out:
-	return ret;
-}
-
-static int ath_ahb_remove(struct platform_device *pdev)
-{
-	struct ar231x_board_config *bcfg = dev_get_platdata(&pdev->dev);
-	struct ieee80211_hw *hw = platform_get_drvdata(pdev);
-	struct ath5k_hw *ah;
-	u32 reg;
-
-	if (!hw)
-		return 0;
-
-	ah = hw->priv;
-
-	if (bcfg->devid >= AR5K_SREV_AR2315_R6) {
-		/* Disable WMAC AHB arbitration */
-		reg = ioread32((void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
-		reg &= ~AR5K_AR2315_AHB_ARB_CTL_WLAN;
-		iowrite32(reg, (void __iomem *) AR5K_AR2315_AHB_ARB_CTL);
-	} else {
-		/*Stop DMA access */
-		reg = ioread32((void __iomem *) AR5K_AR5312_ENABLE);
-		if (to_platform_device(ah->dev)->id == 0)
-			reg &= ~AR5K_AR5312_ENABLE_WLAN0;
-		else
-			reg &= ~AR5K_AR5312_ENABLE_WLAN1;
-		iowrite32(reg, (void __iomem *) AR5K_AR5312_ENABLE);
-	}
-
-	ath5k_deinit_ah(ah);
-	iounmap(ah->iobase);
-	ieee80211_free_hw(hw);
-
-	return 0;
-}
-
-static struct platform_driver ath_ahb_driver = {
-	.probe      = ath_ahb_probe,
-	.remove     = ath_ahb_remove,
-	.driver		= {
-		.name	= "ar231x-wmac",
-		.owner	= THIS_MODULE,
-	},
-};
-
-module_platform_driver(ath_ahb_driver);

drivers/net/wireless/ath/ath5k/ath5k.h +0 -28

index 85316bb3f8c6..ed2468220216 100644
@@ -1647,32 +1647,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);

@@ -1683,8 +1657,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;

drivers/net/wireless/ath/ath5k/base.c +0 -14

index 59a87247aac4..a4a09bb8f2f3 100644
@@ -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 },
 };
 

drivers/net/wireless/ath/ath5k/led.c +0 -6

index 2062d1190556..0beb7e7d6075 100644
@@ -163,20 +163,14 @@ 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);

Signature · 1 line

1.9.3

Quoted 25 lines

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 24 lines

Hi Sergey,

Quoted 20 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 6 lines · Paul Bolle

Quoted 4 lines

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?

Quoted 6 lines

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

Quoted 4 lines

Quoted 2 lines

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?

2014-09-09 22:27 GMT+04:00, John W. Linville <[email protected]>:

Quoted 28 lines · Sergey Ryazanov

Quoted 27 lines

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 26 lines

Hi Sergey,

Quoted 13 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 6 lines · Paul Bolle

Quoted 4 lines

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?

Quoted 6 lines

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)?

Quoted 7 lines

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?

Quoted 6 lines

Quoted 2 lines

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

Quoted 36 lines

2014-09-09 22:27 GMT+04:00, John W. Linville <[email protected]>:

Quoted 35 lines · Sergey Ryazanov

Quoted 24 lines

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 23 lines

Hi Sergey,

Quoted 20 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 6 lines · Paul Bolle

Quoted 4 lines

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?

Quoted 6 lines

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.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 1 line

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.

2014-09-10 15:36 GMT+04:00, Jiri Slaby <[email protected]>:

Quoted 37 lines · Sergey Ryazanov

Quoted 36 lines

2014-09-09 22:27 GMT+04:00, John W. Linville <[email protected]>:

Quoted 35 lines · Sergey Ryazanov

Quoted 24 lines

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 23 lines

Hi Sergey,

Quoted 20 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 6 lines · Paul Bolle

Quoted 4 lines

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?

Quoted 6 lines

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.

Quoted 6 lines

Quoted 4 lines

Quoted 1 line

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?

Quoted 6 lines

Quoted 1 line

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 :)

Quoted 2 lines

The unused code has been a way too long
in the tree now.

Code actively used in owrt firmware and its forks.

Quoted 45 lines · Sergey Ryazanov

2014-09-10 15:36 GMT+04:00, Jiri Slaby <[email protected]>:

Quoted 43 lines · Sergey Ryazanov

Quoted 30 lines

2014-09-09 22:27 GMT+04:00, John W. Linville <[email protected]>:

Quoted 29 lines · Sergey Ryazanov

Quoted 28 lines

2014-09-05 15:33 GMT+04:00 Paul Bolle <[email protected]>:

Quoted 27 lines

Hi Sergey,

Quoted 13 lines · Sergey Ryazanov

2014-09-05 14:10 GMT+04:00, Paul Bolle <[email protected]>:

Quoted 6 lines · Paul Bolle

Quoted 4 lines

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?

Quoted 6 lines

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)?

Quoted 8 lines

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?

Quoted 7 lines

Quoted 6 lines

Quoted 2 lines

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.

Quoted 6 lines

Two days is the last deadline :)

Quoted 2 lines

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??

Quoted 3 lines · John W. Linville

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.

Quoted 1 line

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(-)".

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <richard-/[email protected]>

---
 drivers/iommu/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

drivers/iommu/Kconfig +0 -0

index 20d062d..68b047a 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/mips/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/mips/Kconfig +0 -0

index 792bd22..5b08fe9 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
arch/arm/mach-bcm/Kconfig | 1 -

1 file changed, 1 deletion(-)

arch/arm/mach-bcm/Kconfig +0 -0

index b1aa6a9..8dd5fbf 100644
@@ -19,7 +19,6 @@ config ARCH_BCM_MOBILE

select CPU_V7
select CLKSRC_OF
select GENERIC_CLOCKEVENTS

arch/arm/mach-bcm/Kconfig +0 -1

-	select GENERIC_TIME

select GPIO_BCM_KONA
select SPARSE_IRQ
select TICK_ONESHOT

Signature · 1 line

1.8.4.2

Quoted 16 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
arch/arm/mach-bcm/Kconfig | 1 -

1 file changed, 1 deletion(-)

arch/arm/mach-bcm/Kconfig +0 -0

index b1aa6a9..8dd5fbf 100644
@@ -19,7 +19,6 @@ config ARCH_BCM_MOBILE

select CPU_V7
select CLKSRC_OF
select GENERIC_CLOCKEVENTS

arch/arm/mach-bcm/Kconfig +0 -1

-	select GENERIC_TIME

Quoted 5 lines

select GPIO_BCM_KONA
select SPARSE_IRQ
select TICK_ONESHOT

Signature · 1 line

1.8.4.2

I sent a similar patch in November, maintainers nothing did with it.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/278293

Am 09.02.2014 19:57, schrieb Alexander Shiyan:

Quoted 22 lines

Quoted 21 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
arch/arm/mach-bcm/Kconfig | 1 -

1 file changed, 1 deletion(-)

arch/arm/mach-bcm/Kconfig +0 -0

index b1aa6a9..8dd5fbf 100644
@@ -19,7 +19,6 @@ config ARCH_BCM_MOBILE

select CPU_V7
select CLKSRC_OF
select GENERIC_CLOCKEVENTS
- select GENERIC_TIME
select GPIO_BCM_KONA
select SPARSE_IRQ
select TICK_ONESHOT
--
1.8.4.2

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger<[email protected]>

---
  arch/arm/mach-s3c24xx/Kconfig | 1 -
  1 file changed, 1 deletion(-)

arch/arm/mach-s3c24xx/Kconfig +0 -0

index d876431..1c67f04 100644

The symbol is an orphan, get rid of it.

On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:
Please fix whatever script you're using to generate your mails, it's generating corrupt headers.

sound/soc/samsung/Kconfig config SND_SOC_SAMSUNG_RX1950_UDA1380 · line 148

Quoted 4 lines

config SND_SOC_SAMSUNG_SMDK_WM9713

sound/soc/samsung/Kconfig +1 -1

 	tristate "SoC AC97 Audio support for SMDK with WM9713"
-	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
+	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)

Like I said to Paul this isn't fixing the actual issue - think about why the symbol was there in the first place and why it was removed. There is a problem here but this would make it less likely that it would be properly fixed.

Quoted 4 lines · Mark Brown

On Sun, Feb 09, 2014 at 07:47:52PM +0100, Richard Weinberger wrote:

Please fix whatever script you're using to generate your mails, it's generating corrupt headers.

I think Richard's mail didn't end up on lkml. But it's pretty clear what it must have looked like.

Quoted 9 lines

sound/soc/samsung/Kconfig config SND_SOC_SAMSUNG_RX1950_UDA1380 · line 148

Quoted 4 lines

config SND_SOC_SAMSUNG_SMDK_WM9713

sound/soc/samsung/Kconfig +1 -1

 	tristate "SoC AC97 Audio support for SMDK with WM9713"
-	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310 || MACH_SMDKC210)
+	depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || MACH_SMDKV310)

Like I said to Paul this isn't fixing the actual issue - think about why the symbol was there in the first place and why it was removed. There is a problem here but this would make it less likely that it would be properly fixed.

Would you mind going through this one step at a time, just to make sure _I_ understand what it is that you'd like to see?

If so, to be absolutely sure we start from the same point: do you agree that the above line now effectively reads

    depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)

because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig symbol MACH_SMDKC210?

Quoted 6 lines · Paul Bolle

If so, to be absolutely sure we start from the same point: do you agree that the above line now effectively reads

    depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110 || false || false)

because there's neither a Kconfig symbol MACH_SMDKV310 nor a Kconfig symbol MACH_SMDKC210?

Yes, that's correct. Now, like I say think about what the symbol was there for in the first place.

Quoted 2 lines · Mark Brown

Yes, that's correct. Now, like I say think about what the symbol was there for in the first place.

So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS SoCs"). That commit was part of v3.11. Correct?

Quoted 3 lines · Paul Bolle

So, next step: the Kconfig symbols MACH_SMDKV310 and MACH_SMDKC210 were removed in commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT for EXYNOS SoCs"). That commit was part of v3.11. Correct?

Indeed, so we can see that these platforms were converted to use DT and the symbols were removed as a result. This means that a good fix here is to ensure that the driver can be used with DT platforms.

See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll notice the string "smdk-audio". If you grep that string you get a few hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan v3.10:sound/soc/samsung/smdk_wm9713.c for strings you'll find stuff like "wm9713-hifi", "wm9713-codec", and "soc-audio". But these don't show up in v3.10:arch/arm/mach-exynos/mach-smdkv310.c. So it's not obvious how these two files relate.

And I'm left wondering why SND_SOC_SAMSUNG_SMDK_WM9713 actually depends on (among other symbols) MACH_SMDKV310 and MACH_SMDKC210 in v3.10.

Quoted 7 lines · Paul Bolle

See, if you scan v3.10:arch/arm/mach-exynos/mach-smdkv310.c you'll notice the string "smdk-audio". If you grep that string you get a few hits. But none in v3.10:sound/soc/samsung/smdk_wm9713.c. And if you scan v3.10:sound/soc/samsung/smdk_wm9713.c for strings you'll find stuff like "wm9713-hifi", "wm9713-codec", and "soc-audio". But these don't show up in v3.10:arch/arm/mach-exynos/mach-smdkv310.c. So it's not obvious how these two files relate.

Quoted 2 lines

And I'm left wondering why SND_SOC_SAMSUNG_SMDK_WM9713 actually depends on (among other symbols) MACH_SMDKV310 and MACH_SMDKC210 in v3.10.

The hardware is physically present on those boards but must be selected with DIP switches, the device registration needs to be changed in the kernel when that happens (as the DT must be when it is in use).

That commit is fine with me, of course. I now see no reason to continue my, rather slowly progressing, search for the problem that you wanted to get properly fixed. I suppose another commit already fixed it.

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/nand/Kconfig +0 -0

index 90ff447..a195d57 100644

Quoted 13 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 drivers/mtd/nand/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/nand/Kconfig +0 -0

index 90ff447..a195d57 100644
@@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
 

drivers/mtd/nand/Kconfig config MTD_NAND_SH_FLCTL · line 471

Quoted 7 lines

drivers/mtd/nand/Kconfig +1 -1

 config MTD_NAND_DAVINCI
         tristate "Support NAND on DaVinci/Keystone SoC"
-        depends on ARCH_DAVINCI || (ARCH_KEYSTONE && TI_AEMIF)
+        depends on ARCH_DAVINCI || ARCH_KEYSTONE
         help
 	  Enable the driver for NAND flash chips on Texas Instruments
 	  DaVinci/Keystone processors.

What's strange about the current dependency is that the only aemif code I could find lives at arch/arm/mach-davinci/aemif.c. Is that reachable for code in arch/arm/mach-keystone?

+ Ivan, others

Quoted 14 lines · Paul Bolle

Quoted 13 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
  drivers/mtd/nand/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

drivers/mtd/nand/Kconfig +0 -0

index 90ff447..a195d57 100644
@@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
 

Quoted 10 lines

drivers/mtd/nand/Kconfig config MTD_NAND_SH_FLCTL · line 471

Quoted 7 lines

drivers/mtd/nand/Kconfig +1 -1

  config MTD_NAND_DAVINCI
          tristate "Support NAND on DaVinci/Keystone SoC"
-        depends on ARCH_DAVINCI || (ARCH_KEYSTONE && TI_AEMIF)
+        depends on ARCH_DAVINCI || ARCH_KEYSTONE
          help
  	  Enable the driver for NAND flash chips on Texas Instruments
  	  DaVinci/Keystone processors.

What's strange about the current dependency is that the only aemif code I could find lives at arch/arm/mach-davinci/aemif.c. Is that reachable for code in arch/arm/mach-keystone?

It looks like I merged this code before the supporting aemif driver [1] was merged. I think this is harmless, and so I plan to leave it as-is for now. Or if Ivan prefers, I can drop the Keystone dependency entirely until it is ready.

https://lkml.org/lkml/2013/11/20/283

Brian

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/score/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/score/Kconfig +0 -1

index c75d06a..c7a7b65 100644
@@ -23,19 +23,16 @@ config ARCH_SCORE7
 	bool "SCORE7 processor"
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select CPU_SCORE7
-	select GENERIC_HAS_IOMAP
 
 config MACH_SPCT6600
 	bool "SPCT6600 series based machines"
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select CPU_SCORE7

Quoted 30 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
  arch/score/Kconfig | 3 ---
  1 file changed, 3 deletions(-)

arch/score/Kconfig +0 -3

index c75d06a..c7a7b65 100644
@@ -23,19 +23,16 @@ config ARCH_SCORE7
  	bool "SCORE7 processor"
  	select SYS_SUPPORTS_32BIT_KERNEL
  	select CPU_SCORE7
-	select GENERIC_HAS_IOMAP
 
  config MACH_SPCT6600
  	bool "SPCT6600 series based machines"
  	select SYS_SUPPORTS_32BIT_KERNEL
  	select CPU_SCORE7
-	select GENERIC_HAS_IOMAP
 
  config SCORE_SIM
  	bool "Score simulator"
  	select SYS_SUPPORTS_32BIT_KERNEL
  	select CPU_SCORE7
-	select GENERIC_HAS_IOMAP
  endchoice
 

arch/score/Kconfig config ARCH_SCORE7 · line 38

Quoted 1 line

arch/score/Kconfig +0 -0

  endmenu

Actually, all these select statements can be dropped. I sent a patch to do that about a year ago (but the link to that patch on lkml.org seems
empty: https://lkml.org/lkml/2013/3/6/167 ).

Good luck in getting a reply from the score maintainers. I never got one.

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/score/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/score/Kconfig +0 -4

index c75d06a..c7a7b65 100644
@@ -23,19 +23,16 @@ config ARCH_SCORE7
        bool "SCORE7 processor"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config MACH_SPCT6600
        bool "SPCT6600 series based machines"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config SCORE_SIM
        bool "Score simulator"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 endchoice
 
 endmenu
--

1.8.4.2

Thanks.

Acked-by Lennox Wu <[email protected]>

2014-02-10 2:47 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 33 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/score/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/score/Kconfig +0 -4

index c75d06a..c7a7b65 100644
@@ -23,19 +23,16 @@ config ARCH_SCORE7
        bool "SCORE7 processor"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config MACH_SPCT6600
        bool "SPCT6600 series based machines"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config SCORE_SIM
        bool "Score simulator"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 endchoice
 
 endmenu
--

1.8.4.2

Quoted 3 lines

Thanks.

Acked-by Lennox Wu <[email protected]>

I don't think this oneliner is queued somewhere. Lennox, you're listed as one of the score maintainers: could you perhaps queue this patch?

Paul Bolle

Quoted 34 lines

2014-02-10 2:47 GMT+08:00 Richard Weinberger <[email protected]>:

Quoted 33 lines

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/score/Kconfig | 3 ---
 1 file changed, 3 deletions(-)

arch/score/Kconfig +0 -4

index c75d06a..c7a7b65 100644
@@ -23,19 +23,16 @@ config ARCH_SCORE7
        bool "SCORE7 processor"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config MACH_SPCT6600
        bool "SPCT6600 series based machines"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 
 config SCORE_SIM
        bool "Score simulator"
        select SYS_SUPPORTS_32BIT_KERNEL
        select CPU_SCORE7
-       select GENERIC_HAS_IOMAP
 endchoice
 
 endmenu
--

1.8.4.2

OK, we will merge it into our tree.

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

Lennox,

Quoted 2 lines · Paul Bolle

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

The last few messages in this thread were sent shortly after v3.15-rc1. We're now at v3.16-rc1 and those three references to GENERIC_HAS_IOMAP are still there.

Are there any issues with this patch?

Paul Bolle

2014-06-18 17:10 GMT+08:00 Paul Bolle <[email protected]>:

Quoted 8 lines

Quoted 3 lines · Paul Bolle

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

The last few messages in this thread were sent shortly after v3.15-rc1. We're now at v3.16-rc1 and those three references to GENERIC_HAS_IOMAP are still there.

Quoted 5 lines

Are there any issues with this patch?

Paul Bolle

NO, there is no issue. We just want to push patches in a batched way. The patch will show recently. Thank you.

Guenter, Richard,

Quoted 12 lines · Lennox Wu

2014-06-18 17:10 GMT+08:00 Paul Bolle <[email protected]>:

Quoted 11 lines

Quoted 3 lines · Paul Bolle

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

The last few messages in this thread were sent shortly after v3.15-rc1. We're now at v3.16-rc1 and those three references to GENERIC_HAS_IOMAP are still there.

Are there any issues with this patch?

Quoted 4 lines

Quoted 2 lines

Paul Bolle

NO, there is no issue. We just want to push patches in a batched way. The patch will show recently. Thank you.

And at v3.17-rc3 this patch has still not shown up in mainline. Do you have suggestions for an alternative route to get this triviality finally merged?

Quoted 20 lines

Guenter, Richard,

Quoted 16 lines · Lennox Wu

2014-06-18 17:10 GMT+08:00 Paul Bolle <[email protected]>:

Quoted 4 lines

Quoted 3 lines · Paul Bolle

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

Quoted 9 lines

The last few messages in this thread were sent shortly after v3.15-rc1. We're now at v3.16-rc1 and those three references to GENERIC_HAS_IOMAP are still there.

Are there any issues with this patch?

Paul Bolle

NO, there is no issue. We just want to push patches in a batched way. The patch will show recently. Thank you.

Quoted 4 lines

And at v3.17-rc3 this patch has still not shown up in mainline. Do you have suggestions for an alternative route to get this triviality finally merged?

I merged it with the latest kernel, added Lennox' Ack, and sent it to [email protected]. Let's see what happens.

Am 05.09.2014 15:57, schrieb Guenter Roeck:

Quoted 21 lines · Paul Bolle

Quoted 20 lines

Guenter, Richard,

Quoted 16 lines · Lennox Wu

2014-06-18 17:10 GMT+08:00 Paul Bolle <[email protected]>:

Quoted 4 lines

Quoted 3 lines · Paul Bolle

Quoted 1 line · Lennox Wu

OK, we will merge it into our tree.

Quoted 9 lines

The last few messages in this thread were sent shortly after v3.15-rc1. We're now at v3.16-rc1 and those three references to GENERIC_HAS_IOMAP are still there.

Are there any issues with this patch?

Paul Bolle

NO, there is no issue. We just want to push patches in a batched way. The patch will show recently. Thank you.

Quoted 7 lines

Quoted 4 lines

And at v3.17-rc3 this patch has still not shown up in mainline. Do you have suggestions for an alternative route to get this triviality finally merged?

I merged it with the latest kernel, added Lennox' Ack, and sent it to [email protected]. Let's see what happens.

Thanks a lot Guenther!

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/xtensa/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/xtensa/Kconfig +0 -0

index ba56e11..c1d69ba 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

---
 arch/mn10300/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mn10300/Kconfig +0 -0

index a648de1..4434b54 100644

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Quoted 3 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by David Howells <[email protected]>

Quoted 7 lines · David Howells

Quoted 3 lines · Richard Weinberger

The symbol is an orphan, get rid of it.

Signed-off-by Richard Weinberger <[email protected]>

Acked-by David Howells <[email protected]>

I don't think this oneliner is queued somewhere. David, you're listed as one of the mn10300 maintainers: could you perhaps queue this patch?