While playing with the kconfig parser I noticed some orphan symbols.
This patch series removes them as they are a nop.
Subsystem maintainers, please review carefully maybe some symbols are
left overs of a rename commit and need a rename instead of removing them...
This series was mostly autogenerated.
All patches can also be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rw/misc.git orphan-kconfig
[PATCH 01/28] Remove CPU_MMP3
[PATCH 02/28] Remove OF_I2C
[PATCH 03/28] Remove MACH_BCM2708
[PATCH 04/28] Remove EXYNOS_DEV_SYSMMU
[PATCH 05/28] Remove MPILIB_EXTRA
[PATCH 06/28] Remove PICOXCELL_PC3X3
[PATCH 07/28] Remove CPU_PXA988
[PATCH 08/28] Remove SYS_HAS_DMA_OPS
[PATCH 09/28] Remove ATHEROS_AR231X
[PATCH 10/28] Remove SH_MOBILE
[PATCH 11/28] Remove ARCH_SUPPORTS_MSI
[PATCH 12/28] Remove GENERIC_TIME
[PATCH 13/28] Remove S3C24XX_GPIO_EXTRA64
[PATCH 14/28] Remove MACH_SMDKC210
[PATCH 15/28] Remove TI_AEMIF
[PATCH 16/28] Remove GENERIC_HAS_IOMAP
[PATCH 17/28] Remove USE_GENERIC_SMP_HELPERS
[PATCH 18/28] Remove MN10300_PROC_MN2WS0038
[PATCH 19/28] Remove SI4713
[PATCH 20/28] Remove OMAP_PM_SRF
[PATCH 21/28] Remove CPU_SUBTYPE_SH7764
[PATCH 22/28] Remove S3C24XX_GPIO_EXTRA128
[PATCH 23/28] Remove MACH_OMAP_H4_OTG
[PATCH 24/28] Remove DEPRECATED
[PATCH 25/28] Remove MACH_SMDKV310
[PATCH 26/28] Remove LOCAL_TIMERS
[PATCH 27/28] Remove ARC_HAS_COH_RTSC
[PATCH 28/28] Remove LOCAL_TIMERS
Thanks,
//richard
Cc: [email protected]
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(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 792bd22..5b08fe9 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -782,7 +782,6 @@ config NLM_XLP_BOARD
select CEVT_R4K
select CSRC_R4K
select IRQ_CPU
- select ARCH_SUPPORTS_MSI
select ZONE_DMA32 if 64BIT
select SYNC_R4K
select SYS_HAS_EARLY_PRINTK
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/mn10300/Kconfig.debug | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mn10300/Kconfig.debug b/arch/mn10300/Kconfig.debug
index 94efb3e..af18047 100644
--- a/arch/mn10300/Kconfig.debug
+++ b/arch/mn10300/Kconfig.debug
@@ -32,7 +32,7 @@ config KPROBES
config GDBSTUB
bool "Remote GDB kernel debugging"
- depends on DEBUG_KERNEL && DEPRECATED
+ depends on DEBUG_KERNEL
select DEBUG_INFO
select FRAME_POINTER
help
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/arm/mach-omap2/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 653b489..2817f1f 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -54,7 +54,6 @@ config SOC_OMAP5
select ARM_GIC
select CPU_V7
select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if LOCAL_TIMERS
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
select ARM_ERRATA_798181 if SMP
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
drivers/usb/gadget/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8154165..42f017a 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -226,7 +226,7 @@ config USB_GR_UDC
config USB_OMAP
tristate "OMAP USB Device Controller"
depends on ARCH_OMAP1
- select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3 || MACH_OMAP_H4_OTG
+ select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
help
Many Texas Instruments OMAP processors have flexible full
speed USB device controllers, with support for up to 30
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/arc/plat-arcfpga/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arc/plat-arcfpga/Kconfig b/arch/arc/plat-arcfpga/Kconfig
index 295cefe..33058aa 100644
--- a/arch/arc/plat-arcfpga/Kconfig
+++ b/arch/arc/plat-arcfpga/Kconfig
@@ -33,7 +33,6 @@ config ISS_SMP_EXTN
bool "ARC SMP Extensions (ISS Models only)"
default n
depends on SMP
- select ARC_HAS_COH_RTSC
help
SMP Extensions to ARC700, in a "simulation only" Model, supported in
ARC ISS (Instruction Set Simulator).
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/arm/mach-shmobile/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 3386406..c055388 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -8,7 +8,6 @@ config ARCH_SHMOBILE_MULTI
select CPU_V7
select GENERIC_CLOCKEVENTS
select HAVE_ARM_SCU if SMP
- select HAVE_ARM_TWD if LOCAL_TIMERS
select HAVE_SMP
select ARM_GIC
select MIGHT_HAVE_CACHE_L2X0
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
drivers/staging/tidspbridge/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig
index 1b6d581..b5e74e9 100644
--- a/drivers/staging/tidspbridge/Kconfig
+++ b/drivers/staging/tidspbridge/Kconfig
@@ -17,7 +17,7 @@ menuconfig TIDSPBRIDGE
config TIDSPBRIDGE_DVFS
bool "Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)"
- depends on TIDSPBRIDGE && OMAP_PM_SRF && CPU_FREQ
+ depends on TIDSPBRIDGE && CPU_FREQ
help
DVFS allows DSP Bridge to initiate the operating point change to
scale the chip voltage and frequency in order to match the
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
arch/sh/drivers/dma/Kconfig | 5 ++---
arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/sh/drivers/dma/Kconfig b/arch/sh/drivers/dma/Kconfig
index cfd5b90..e07afe8 100644
--- a/arch/sh/drivers/dma/Kconfig
+++ b/arch/sh/drivers/dma/Kconfig
@@ -12,9 +12,8 @@ config SH_DMA_IRQ_MULTI
default y if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7751 || \
CPU_SUBTYPE_SH7750S || CPU_SUBTYPE_SH7750R || \
CPU_SUBTYPE_SH7751R || CPU_SUBTYPE_SH7091 || \
- CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7764 || \
- CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || \
- CPU_SUBTYPE_SH7760
+ CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7780 || \
+ CPU_SUBTYPE_SH7785 CPU_SUBTYPE_SH7760
config SH_DMA_API
depends on SH_DMA
diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
index 02788b6..9cd81e5 100644
--- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
+++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
@@ -32,7 +32,6 @@
#define CHCR_TS_HIGH_SHIFT (20 - 2) /* 2 bits for shifted low TS */
#elif defined(CONFIG_CPU_SUBTYPE_SH7757) || \
defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764) || \
defined(CONFIG_CPU_SUBTYPE_SH7780) || \
defined(CONFIG_CPU_SUBTYPE_SH7785)
#define CHCR_TS_LOW_MASK 0x00000018
diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
index 89afb65..8ceccce 100644
--- a/arch/sh/include/cpu-sh4a/cpu/dma.h
+++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
@@ -14,8 +14,7 @@
#define DMTE4_IRQ evt2irq(0xb80)
#define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
#define SH_DMAC_BASE0 0xFE008020
-#elif defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764)
+#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
#define DMTE0_IRQ evt2irq(0x640)
#define DMTE4_IRQ evt2irq(0x780)
#define DMAE0_IRQ evt2irq(0x6c0)
--
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(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 1c67f04..bb1fa603 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -561,7 +561,6 @@ config MACH_OSIRIS
select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
select S3C2440_XTAL_12000000
select S3C24XX_DCLK
- select S3C24XX_GPIO_EXTRA128
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_NAND
select S3C_DEV_USB_HOST
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
drivers/iommu/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 20d062d..68b047a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -206,8 +206,7 @@ config SHMOBILE_IPMMU_TLB
config SHMOBILE_IOMMU
bool "IOMMU for Renesas IPMMU/IPMMUI"
default n
- depends on ARM
- depends on SH_MOBILE || COMPILE_TEST
+ depends on ARM || COMPILE_TEST
select IOMMU_API
select ARM_DMA_USE_IOMMU
select SHMOBILE_IPMMU
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
---
drivers/media/radio/si4713/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/radio/si4713/Kconfig b/drivers/media/radio/si4713/Kconfig
index a7c3ba8..ed51ed0 100644
--- a/drivers/media/radio/si4713/Kconfig
+++ b/drivers/media/radio/si4713/Kconfig
@@ -1,7 +1,6 @@
config USB_SI4713
tristate "Silicon Labs Si4713 FM Radio Transmitter support with USB"
depends on USB && RADIO_SI4713
- select SI4713
---help---
This is a driver for USB devices with the Silicon Labs SI4713
chip. Currently these devices are known to work.
@@ -16,7 +15,6 @@ config USB_SI4713
config PLATFORM_SI4713
tristate "Silicon Labs Si4713 FM Radio Transmitter support with I2C"
depends on I2C && RADIO_SI4713
- select SI4713
---help---
This is a driver for I2C devices with the Silicon Labs SI4713
chip.
--
1.8.4.2
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(-)
diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
index a648de1..4434b54 100644
--- a/arch/mn10300/Kconfig
+++ b/arch/mn10300/Kconfig
@@ -181,7 +181,7 @@ endmenu
config SMP
bool "Symmetric multi-processing support"
default y
- depends on MN10300_PROC_MN2WS0038 || MN10300_PROC_MN2WS0050
+ depends on MN10300_PROC_MN2WS0050
---help---
This enables support for systems with more than one CPU. If you have
a system with only one CPU, say N. If you have a system with more
--
1.8.4.2
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(-)
diff --git a/arch/score/Kconfig b/arch/score/Kconfig
index c75d06a..c7a7b65 100644
--- a/arch/score/Kconfig
+++ b/arch/score/Kconfig
@@ -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
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(-)
diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index ba56e11..c1d69ba 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -135,7 +135,6 @@ config HAVE_SMP
config SMP
bool "Enable Symmetric multi-processing support"
depends on HAVE_SMP
- select USE_GENERIC_SMP_HELPERS
select GENERIC_SMP_IDLE_THREAD
help
Enabled SMP Software; allows more than one CPU/CORE
--
1.8.4.2
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(-)
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 03a6eb9..0320c7d 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -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).
--
1.8.4.2
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(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 90ff447..a195d57 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
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.
--
1.8.4.2
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(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 79bbc21..20d062d 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -178,7 +178,7 @@ config TEGRA_IOMMU_SMMU
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
--
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(-)
diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d876431..1c67f04 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -521,7 +521,6 @@ config MACH_ANUBIS
select HAVE_PATA_PLATFORM
select S3C2440_XTAL_12000000
select S3C24XX_DCLK
- select S3C24XX_GPIO_EXTRA64
select S3C24XX_SIMTEC_PM if PM
select S3C_DEV_USB_HOST
help
--
1.8.4.2
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(-)
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index b1aa6a9..8dd5fbf 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -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]>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 9bed1a2..e4382ec 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -308,7 +308,7 @@ config DMA_OMAP
config DMA_BCM2835
tristate "BCM2835 DMA engine support"
- depends on (ARCH_BCM2835 || MACH_BCM2708)
+ depends on ARCH_BCM2835
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
--
1.8.4.2
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(-)
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);
--
1.8.4.2
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(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f5ed031..de17c55 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -387,7 +387,7 @@ config I2C_CBUS_GPIO
config I2C_CPM
tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
- depends on (CPM1 || CPM2) && OF_I2C
+ depends on CPM1 || CPM2
help
This supports the use of the I2C interface on Freescale
processors with CPM1 or CPM2.
--
1.8.4.2
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(-)
diff --git a/drivers/video/mmp/Kconfig b/drivers/video/mmp/Kconfig
index 969925d..f37bd6c 100644
--- a/drivers/video/mmp/Kconfig
+++ b/drivers/video/mmp/Kconfig
@@ -1,6 +1,6 @@
menuconfig MMP_DISP
tristate "Marvell MMP Display Subsystem support"
- depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
+ depends on CPU_PXA910 || CPU_MMP2
help
Marvell Display Subsystem support.
diff --git a/drivers/video/mmp/hw/Kconfig b/drivers/video/mmp/hw/Kconfig
index 57b03e2..95e8ec2 100644
--- a/drivers/video/mmp/hw/Kconfig
+++ b/drivers/video/mmp/hw/Kconfig
@@ -2,7 +2,7 @@ if MMP_DISP
config MMP_DISP_CONTROLLER
bool "mmp display controller hw support"
- depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
+ depends on CPU_PXA910 || CPU_MMP2
default n
help
Marvell MMP display hw controller support
diff --git a/drivers/video/mmp/hw/mmp_ctrl.h b/drivers/video/mmp/hw/mmp_ctrl.h
index 53301cf..56fdeab 100644
--- a/drivers/video/mmp/hw/mmp_ctrl.h
+++ b/drivers/video/mmp/hw/mmp_ctrl.h
@@ -167,11 +167,7 @@ struct lcd_regs {
PN2_IOPAD_CONTROL) : LCD_TOP_CTRL)
/* dither configure */
-#ifdef CONFIG_CPU_PXA988
-#define LCD_DITHER_CTRL (0x01EC)
-#else
#define LCD_DITHER_CTRL (0x00A0)
-#endif
#define DITHER_TBL_INDEX_SEL(s) ((s) << 16)
#define DITHER_MODE2(m) ((m) << 12)
@@ -186,15 +182,6 @@ struct lcd_regs {
#define DITHER_EN1 (1)
/* dither table data was fixed by video bpp of input and output*/
-#ifdef CONFIG_CPU_PXA988
-#define DITHER_TB_4X4_INDEX0 (0x6e4ca280)
-#define DITHER_TB_4X4_INDEX1 (0x5d7f91b3)
-#define DITHER_TB_4X8_INDEX0 (0xb391a280)
-#define DITHER_TB_4X8_INDEX1 (0x7f5d6e4c)
-#define DITHER_TB_4X8_INDEX2 (0x80a291b3)
-#define DITHER_TB_4X8_INDEX3 (0x4c6e5d7f)
-#define LCD_DITHER_TBL_DATA (0x01F0)
-#else
#define DITHER_TB_4X4_INDEX0 (0x3b19f7d5)
#define DITHER_TB_4X4_INDEX1 (0x082ac4e6)
#define DITHER_TB_4X8_INDEX0 (0xf7d508e6)
@@ -202,7 +189,6 @@ struct lcd_regs {
#define DITHER_TB_4X8_INDEX2 (0xc4e6d5f7)
#define DITHER_TB_4X8_INDEX3 (0x082a193b)
#define LCD_DITHER_TBL_DATA (0x00A4)
-#endif
/* Video Frame 0&1 start address registers */
#define LCD_SPU_DMA_START_ADDR_Y0 0x00C0
@@ -933,16 +919,9 @@ struct lcd_regs {
#define LCD_PN2_SQULN2_CTRL (0x02F0)
#define ALL_LAYER_ALPHA_SEL (0x02F4)
-/* pxa988 has different MASTER_CTRL from MMP3/MMP2 */
-#ifdef CONFIG_CPU_PXA988
-#define TIMING_MASTER_CONTROL (0x01F4)
-#define MASTER_ENH(id) (1 << ((id) + 5))
-#define MASTER_ENV(id) (1 << ((id) + 6))
-#else
#define TIMING_MASTER_CONTROL (0x02F8)
#define MASTER_ENH(id) (1 << (id))
#define MASTER_ENV(id) (1 << ((id) + 4))
-#endif
#define DSI_START_SEL_SHIFT(id) (((id) << 1) + 8)
#define timing_master_config(path, dsi_id, lcd_id) \
@@ -1312,19 +1291,8 @@ struct dsi_regs {
#define DSI_PHY_TIME_3_CFG_CSR_TIME_REQRDY_MASK (0xff)
#define DSI_PHY_TIME_3_CFG_CSR_TIME_REQRDY_SHIFT 0
-/*
- * DSI timings
- * PXA988 has diffrent ESC CLK with MMP2/MMP3
- * it will be used in dsi_set_dphy() in pxa688_phy.c
- * as low power mode clock.
- */
-#ifdef CONFIG_CPU_PXA988
-#define DSI_ESC_CLK 52 /* Unit: Mhz */
-#define DSI_ESC_CLK_T 19 /* Unit: ns */
-#else
#define DSI_ESC_CLK 66 /* Unit: Mhz */
#define DSI_ESC_CLK_T 15 /* Unit: ns */
-#endif
/* LVDS */
/* LVDS_PHY_CTRL */
--
1.8.4.2
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(-)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index dcae3a7..792bd22 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1396,7 +1396,6 @@ config CPU_CAVIUM_OCTEON
select LIBFDT
select USE_OF
select USB_EHCI_BIG_ENDIAN_MMIO
- select SYS_HAS_DMA_OPS
select MIPS_L1_CACHE_SHIFT_7
help
The Cavium Octeon processor is a highly integrated chip containing
--
1.8.4.2
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[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(-)
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 7d1451d..b9b1c52 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -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
diff --git a/drivers/video/mmp/Kconfig b/drivers/video/mmp/Kconfig
index e9ea39e..969925d 100644
--- a/drivers/video/mmp/Kconfig
+++ b/drivers/video/mmp/Kconfig
@@ -1,6 +1,6 @@
menuconfig MMP_DISP
tristate "Marvell MMP Display Subsystem support"
- depends on CPU_PXA910 || CPU_MMP2 || CPU_MMP3 || CPU_PXA988
+ depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
help
Marvell Display Subsystem support.
diff --git a/drivers/video/mmp/hw/Kconfig b/drivers/video/mmp/hw/Kconfig
index 02f109a..57b03e2 100644
--- a/drivers/video/mmp/hw/Kconfig
+++ b/drivers/video/mmp/hw/Kconfig
@@ -2,7 +2,7 @@ if MMP_DISP
config MMP_DISP_CONTROLLER
bool "mmp display controller hw support"
- depends on CPU_PXA910 || CPU_MMP2 || CPU_MMP3 || CPU_PXA988
+ depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
default n
help
Marvell MMP display hw controller support
--
1.8.4.2
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(-)
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 2f2b084..eab6056 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -253,7 +253,7 @@ config HW_RANDOM_NOMADIK
config HW_RANDOM_PICOXCELL
tristate "Picochip picoXcell true random number generator support"
- depends on HW_RANDOM && ARCH_PICOXCELL && PICOXCELL_PC3X3
+ depends on HW_RANDOM && ARCH_PICOXCELL
---help---
This driver provides kernel-side support for the Random Number
Generator hardware found on Picochip PC3x3 and later devices.
--
1.8.4.2
> 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(-)
>
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index b1aa6a9..8dd5fbf 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -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
I sent a similar patch in November, maintainers nothing did with it.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/278293
---
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
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.
On 02/09/2014 07:47 PM, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
NACK.
It's not an orphan, it's a typo. It should be I2C_SI4713.
Paul, Richard, let me handle this. I'll make a patch for this tomorrow (I believe
there was a report about a missing I2C dependency as well) and make sure it ends
up in a pull request for 3.14.
Regards,
Hans
>
> Signed-off-by: Richard Weinberger <[email protected]>
> ---
> drivers/media/radio/si4713/Kconfig | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/media/radio/si4713/Kconfig b/drivers/media/radio/si4713/Kconfig
> index a7c3ba8..ed51ed0 100644
> --- a/drivers/media/radio/si4713/Kconfig
> +++ b/drivers/media/radio/si4713/Kconfig
> @@ -1,7 +1,6 @@
> config USB_SI4713
> tristate "Silicon Labs Si4713 FM Radio Transmitter support with USB"
> depends on USB && RADIO_SI4713
> - select SI4713
> ---help---
> This is a driver for USB devices with the Silicon Labs SI4713
> chip. Currently these devices are known to work.
> @@ -16,7 +15,6 @@ config USB_SI4713
> config PLATFORM_SI4713
> tristate "Silicon Labs Si4713 FM Radio Transmitter support with I2C"
> depends on I2C && RADIO_SI4713
> - select SI4713
> ---help---
> This is a driver for I2C devices with the Silicon Labs SI4713
> chip.
>
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
> ---
> arch/mn10300/Kconfig.debug | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mn10300/Kconfig.debug b/arch/mn10300/Kconfig.debug
> index 94efb3e..af18047 100644
> --- a/arch/mn10300/Kconfig.debug
> +++ b/arch/mn10300/Kconfig.debug
> @@ -32,7 +32,7 @@ config KPROBES
>
> config GDBSTUB
> bool "Remote GDB kernel debugging"
> - depends on DEBUG_KERNEL && DEPRECATED
> + depends on DEBUG_KERNEL
But now you've enabled a lot of stuff that, as far as I can tell, could
not have been built since v2.6.39.
The proper fix would be to remove GDBSTUB and everything that depends on
it. I tried to do that once and it turned out to be much more work than
I expected. So perhaps we should just do s/DEPRECATED/BROKEN/ and let
the mn10300 maintainers deal with this.
> select DEBUG_INFO
> select FRAME_POINTER
> help
Paul Bolle
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
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: Paul Bolle <[email protected]>
This Kconfig symbol was removed in commit 7d087a54aed ("ARC: [SMP]
Disallow RTSC"), merged in v3.13.
> ---
> arch/arc/plat-arcfpga/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arc/plat-arcfpga/Kconfig b/arch/arc/plat-arcfpga/Kconfig
> index 295cefe..33058aa 100644
> --- a/arch/arc/plat-arcfpga/Kconfig
> +++ b/arch/arc/plat-arcfpga/Kconfig
> @@ -33,7 +33,6 @@ config ISS_SMP_EXTN
> bool "ARC SMP Extensions (ISS Models only)"
> default n
> depends on SMP
> - select ARC_HAS_COH_RTSC
> help
> SMP Extensions to ARC700, in a "simulation only" Model, supported in
> ARC ISS (Instruction Set Simulator).
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
> ---
> drivers/staging/tidspbridge/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/tidspbridge/Kconfig b/drivers/staging/tidspbridge/Kconfig
> index 1b6d581..b5e74e9 100644
> --- a/drivers/staging/tidspbridge/Kconfig
> +++ b/drivers/staging/tidspbridge/Kconfig
> @@ -17,7 +17,7 @@ menuconfig TIDSPBRIDGE
>
> config TIDSPBRIDGE_DVFS
> bool "Enable Bridge Dynamic Voltage and Frequency Scaling (DVFS)"
> - depends on TIDSPBRIDGE && OMAP_PM_SRF && CPU_FREQ
> + depends on TIDSPBRIDGE && CPU_FREQ
You're effectively enabling the TIDSPBRIDGE_DVFS code here. As far as
I'm aware that code has _never_ been buildable (ever since it got merged
in v2.6.36).
I think TIDSPBRIDGE_DVFS (and everything depending on it) might better
be removed.
Paul Bolle
> help
> DVFS allows DSP Bridge to initiate the operating point change to
> scale the chip voltage and frequency in order to match the
On Sun, Feb 09, 2014 at 07:48:01PM +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: Aaro Koskinen <[email protected]>
A.
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index f5ed031..de17c55 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -387,7 +387,7 @@ config I2C_CBUS_GPIO
>
> config I2C_CPM
> tristate "Freescale CPM1 or CPM2 (MPC8xx/826x)"
> - depends on (CPM1 || CPM2) && OF_I2C
> + depends on CPM1 || CPM2
> help
> This supports the use of the I2C interface on Freescale
> processors with CPM1 or CPM2.
This needs testing. Since when is OF_I2C orphaned? Ie, when was the last
time it was possible to set I2C_CPM?
Paul Bolle
Am 09.02.2014 19:57, schrieb Alexander Shiyan:
>> 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(-)
>>
>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>> index b1aa6a9..8dd5fbf 100644
>> --- a/arch/arm/mach-bcm/Kconfig
>> +++ b/arch/arm/mach-bcm/Kconfig
>> @@ -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
>
> I sent a similar patch in November, maintainers nothing did with it.
> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/278293
Then it is time to push it. :D
Thanks,
//richard
Am 09.02.2014 20:13, schrieb Hans Verkuil:
> On 02/09/2014 07:47 PM, Richard Weinberger wrote:
>> The symbol is an orphan, get rid of it.
>
> NACK.
>
> It's not an orphan, it's a typo. It should be I2C_SI4713.
>
> Paul, Richard, let me handle this. I'll make a patch for this tomorrow (I believe
> there was a report about a missing I2C dependency as well) and make sure it ends
> up in a pull request for 3.14.
This is perfectly fine. Thanks for sorting this out!
Thanks,
//richard
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 9bed1a2..e4382ec 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -308,7 +308,7 @@ config DMA_OMAP
>
> config DMA_BCM2835
> tristate "BCM2835 DMA engine support"
> - depends on (ARCH_BCM2835 || MACH_BCM2708)
> + depends on ARCH_BCM2835
> select DMA_ENGINE
> select DMA_VIRTUAL_CHANNELS
>
I sent an identical patch (with a more verbose explanation) a few hours
ago. But I'm fine with this one too.
Paul Bolle
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 <[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.
Sorry, we don't maintain out of tree code.
Thanks,
//richard
Am 09.02.2014 20:38, schrieb Paul Bolle:
> On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
>> The symbol is an orphan, get rid of it.
>>
>> Signed-off-by: Richard Weinberger <[email protected]>
>> ---
>> arch/mn10300/Kconfig.debug | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/mn10300/Kconfig.debug b/arch/mn10300/Kconfig.debug
>> index 94efb3e..af18047 100644
>> --- a/arch/mn10300/Kconfig.debug
>> +++ b/arch/mn10300/Kconfig.debug
>> @@ -32,7 +32,7 @@ config KPROBES
>>
>> config GDBSTUB
>> bool "Remote GDB kernel debugging"
>> - depends on DEBUG_KERNEL && DEPRECATED
>> + depends on DEBUG_KERNEL
>
> But now you've enabled a lot of stuff that, as far as I can tell, could
> not have been built since v2.6.39.
This is by design. If the code does not build/work it needs to be fixed or removed.
Thanks,
//richard
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 79bbc21..20d062d 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -178,7 +178,7 @@ config TEGRA_IOMMU_SMMU
>
> 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).
Paul Bolle
On Sun, 2014-02-09 at 21:04 +0100, Richard Weinberger wrote:
> Am 09.02.2014 20:38, schrieb Paul Bolle:
> > But now you've enabled a lot of stuff that, as far as I can tell, could
> > not have been built since v2.6.39.
>
> This is by design. If the code does not build/work it needs to be fixed or removed.
If that was the design goal of this patch (and similar patches you've
sent) it would have been proper to at least say a few words along those
lines in the commit explanation.
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: Paul Bolle <[email protected]>
> ---
> crypto/asymmetric_keys/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> index 03a6eb9..0320c7d 100644
> --- a/crypto/asymmetric_keys/Kconfig
> +++ b/crypto/asymmetric_keys/Kconfig
> @@ -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 ).
Paul Bolle
Am 09.02.2014 21:15, schrieb Paul Bolle:
> On Sun, 2014-02-09 at 21:04 +0100, Richard Weinberger wrote:
>> Am 09.02.2014 20:38, schrieb Paul Bolle:
>>> But now you've enabled a lot of stuff that, as far as I can tell, could
>>> not have been built since v2.6.39.
>>
>> This is by design. If the code does not build/work it needs to be fixed or removed.
>
> If that was the design goal of this patch (and similar patches you've
> sent) it would have been proper to at least say a few words along those
> lines in the commit explanation.
I assumed that every kernel developer is aware of that fact that unreachable/dead code
should be removed.
That said, feel free to use my patch series as base for your work.
The series is only a by-product of some "real" work.
Thanks,
//richard
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
> ---
> drivers/iommu/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 20d062d..68b047a 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -206,8 +206,7 @@ config SHMOBILE_IPMMU_TLB
> config SHMOBILE_IOMMU
> bool "IOMMU for Renesas IPMMU/IPMMUI"
> default n
> - depends on ARM
> - depends on SH_MOBILE || COMPILE_TEST
> + depends on ARM || COMPILE_TEST
It seems ARCH_SHMOBILE was intended, see
https://lkml.org/lkml/2014/2/8/256 .
> select IOMMU_API
> select ARM_DMA_USE_IOMMU
> select SHMOBILE_IPMMU
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 2f2b084..eab6056 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -253,7 +253,7 @@ config HW_RANDOM_NOMADIK
>
> config HW_RANDOM_PICOXCELL
> tristate "Picochip picoXcell true random number generator support"
> - depends on HW_RANDOM && ARCH_PICOXCELL && PICOXCELL_PC3X3
> + depends on HW_RANDOM && ARCH_PICOXCELL
> ---help---
> This driver provides kernel-side support for the Random Number
> Generator hardware found on Picochip PC3x3 and later devices.
So that random number generator is now unbuildable. For the record: this
was already an issue in May 2013:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/168283.html . Perhaps the picoxcell-rng could be removed (an merged again if PICOXCELL_PC3X3 gets added).
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
> index 792bd22..5b08fe9 100644
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -782,7 +782,6 @@ config NLM_XLP_BOARD
> select CEVT_R4K
> select CSRC_R4K
> select IRQ_CPU
> - select ARCH_SUPPORTS_MSI
> select ZONE_DMA32 if 64BIT
> select SYNC_R4K
> select SYS_HAS_EARLY_PRINTK
I sent an identical patch (with a more verbose explanation) yesterday.
But I'm fine with this one too.
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: Paul Bolle <[email protected]>
> ---
> arch/mn10300/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig
> index a648de1..4434b54 100644
> --- a/arch/mn10300/Kconfig
> +++ b/arch/mn10300/Kconfig
> @@ -181,7 +181,7 @@ endmenu
> config SMP
> bool "Symmetric multi-processing support"
> default y
> - depends on MN10300_PROC_MN2WS0038 || MN10300_PROC_MN2WS0050
> + depends on MN10300_PROC_MN2WS0050
> ---help---
> This enables support for systems with more than one CPU. If you have
> a system with only one CPU, say N. If you have a system with more
I tried this one too in 2013: https://lkml.org/lkml/2013/5/15/144 .
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 90ff447..a195d57 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
>
> 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?
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/arch/score/Kconfig b/arch/score/Kconfig
> index c75d06a..c7a7b65 100644
> --- a/arch/score/Kconfig
> +++ b/arch/score/Kconfig
> @@ -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
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.
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
> index ba56e11..c1d69ba 100644
> --- a/arch/xtensa/Kconfig
> +++ b/arch/xtensa/Kconfig
> @@ -135,7 +135,6 @@ config HAVE_SMP
> config SMP
> bool "Enable Symmetric multi-processing support"
> depends on HAVE_SMP
> - select USE_GENERIC_SMP_HELPERS
> select GENERIC_SMP_IDLE_THREAD
> help
> Enabled SMP Software; allows more than one CPU/CORE
I sent an identical patch (with a more verbose explanation) a few hours
ago. But this one is OK too.
Paul Bolle
On 02/09/2014 12:04 PM, Richard Weinberger wrote:
> Am 09.02.2014 20:38, schrieb Paul Bolle:
>> On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
>>> The symbol is an orphan, get rid of it.
>>>
>>> Signed-off-by: Richard Weinberger <[email protected]>
>>> ---
>>> arch/mn10300/Kconfig.debug | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/mn10300/Kconfig.debug b/arch/mn10300/Kconfig.debug
>>> index 94efb3e..af18047 100644
>>> --- a/arch/mn10300/Kconfig.debug
>>> +++ b/arch/mn10300/Kconfig.debug
>>> @@ -32,7 +32,7 @@ config KPROBES
>>>
>>> config GDBSTUB
>>> bool "Remote GDB kernel debugging"
>>> - depends on DEBUG_KERNEL && DEPRECATED
>>> + depends on DEBUG_KERNEL
>>
>> But now you've enabled a lot of stuff that, as far as I can tell, could
>> not have been built since v2.6.39.
>
> This is by design. If the code does not build/work it needs to be fixed or removed.
>
I could understand if you would replace DEPRECATED with BROKEN,
but causing a potentially large number of broken builds and
then leave it to others to clean up the resulting mess doesn't
make any sense to me and should, in my opinion, be rejected.
Guenter
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Paul Mundt had something similar queued a year ago:
https://lkml.org/lkml/2013/3/11/211 . What happened?
Paul Bolle
> arch/sh/drivers/dma/Kconfig | 5 ++---
> arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
> arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/sh/drivers/dma/Kconfig b/arch/sh/drivers/dma/Kconfig
> index cfd5b90..e07afe8 100644
> --- a/arch/sh/drivers/dma/Kconfig
> +++ b/arch/sh/drivers/dma/Kconfig
> @@ -12,9 +12,8 @@ config SH_DMA_IRQ_MULTI
> default y if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7751 || \
> CPU_SUBTYPE_SH7750S || CPU_SUBTYPE_SH7750R || \
> CPU_SUBTYPE_SH7751R || CPU_SUBTYPE_SH7091 || \
> - CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7764 || \
> - CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || \
> - CPU_SUBTYPE_SH7760
> + CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7780 || \
> + CPU_SUBTYPE_SH7785 CPU_SUBTYPE_SH7760
>
> config SH_DMA_API
> depends on SH_DMA
> diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> index 02788b6..9cd81e5 100644
> --- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
> +++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> @@ -32,7 +32,6 @@
> #define CHCR_TS_HIGH_SHIFT (20 - 2) /* 2 bits for shifted low TS */
> #elif defined(CONFIG_CPU_SUBTYPE_SH7757) || \
> defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> - defined(CONFIG_CPU_SUBTYPE_SH7764) || \
> defined(CONFIG_CPU_SUBTYPE_SH7780) || \
> defined(CONFIG_CPU_SUBTYPE_SH7785)
> #define CHCR_TS_LOW_MASK 0x00000018
> diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
> index 89afb65..8ceccce 100644
> --- a/arch/sh/include/cpu-sh4a/cpu/dma.h
> +++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
> @@ -14,8 +14,7 @@
> #define DMTE4_IRQ evt2irq(0xb80)
> #define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
> #define SH_DMAC_BASE0 0xFE008020
> -#elif defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> - defined(CONFIG_CPU_SUBTYPE_SH7764)
> +#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
> #define DMTE0_IRQ evt2irq(0x640)
> #define DMTE4_IRQ evt2irq(0x780)
> #define DMAE0_IRQ evt2irq(0x6c0)
On 02/09/2014 12:59 PM, Paul Bolle wrote:
> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
>> 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(-)
>>
>> diff --git a/arch/score/Kconfig b/arch/score/Kconfig
>> index c75d06a..c7a7b65 100644
>> --- a/arch/score/Kconfig
>> +++ b/arch/score/Kconfig
>> @@ -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
>
> 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.
>
You could (and maybe should) try again. They maintainers have been
a bit more responsive after I suggested to remove the architecture.
Guenter
Am 09.02.2014 22:35, schrieb Guenter Roeck:
> I could understand if you would replace DEPRECATED with BROKEN,
> but causing a potentially large number of broken builds and
> then leave it to others to clean up the resulting mess doesn't
> make any sense to me and should, in my opinion, be rejected.
Currently the mess is hidden by bad Kconfig dependencies.
We have to face it. :)
Of course, if the maintainer wants me or Paul to remove the resulting
mess to I'm fine with that...
Thanks,
//richard
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
I don't think a symbol with that name was ever part of the tree (but I
didn't look past v2.6.12). It seems just a typo, but it's unclear what
was intended here. It's a nop now, so safe to remove.
> Signed-off-by: Richard Weinberger <[email protected]>
So, perhaps Richard should update the commit explanation. But I'm fine
with the patch itself:
Acked-by: Paul Bolle <[email protected]>
Paul Bolle
On Sunday 09 February 2014, Richard Weinberger wrote:
>Am 09.02.2014 22:35, schrieb Guenter Roeck:
>> I could understand if you would replace DEPRECATED with BROKEN,
>> but causing a potentially large number of broken builds and
>> then leave it to others to clean up the resulting mess doesn't
>> make any sense to me and should, in my opinion, be rejected.
>
>Currently the mess is hidden by bad Kconfig dependencies.
>We have to face it. :)
And much of it is in a bad make oldconfig that I can't date, but all of the
multimedia stuff has been stripped and I can no longer use my pcHDTV3000
card as just one for instance. I just tested it, using an oldconfig that
contained several hundred bits and pieces under the ATSC & DVB headers,
after the oldconfig was done, all that was stripped from the new one, every
trace of it. That was working code guys, what the hell? Kconfig could
have problems, but the oldconfig output being stripped is a much larger
one. First problems first. Then you can really see how fubared kconfig
is.
>Of course, if the maintainer wants me or Paul to remove the resulting
>mess to I'm fine with that...
>
>Thanks,
>//richard
>--
>To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>in the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
This symbol first popped up as a dependency in v3.6, through commit
3d4eb9dfa3e8 ("usb: gadget: mv: Add USB 3.0 device driver for Marvell
PXA2128 chip."). The Kconfig symbol itself was never added.
> diff --git a/drivers/video/mmp/hw/Kconfig b/drivers/video/mmp/hw/Kconfig
> index 02f109a..57b03e2 100644
> --- a/drivers/video/mmp/hw/Kconfig
> +++ b/drivers/video/mmp/hw/Kconfig
> @@ -2,7 +2,7 @@ if MMP_DISP
>
> config MMP_DISP_CONTROLLER
> bool "mmp display controller hw support"
> - depends on CPU_PXA910 || CPU_MMP2 || CPU_MMP3 || CPU_PXA988
> + depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
> default n
> help
> Marvell MMP display hw controller support
You should remove the reference to MMP3 in the help text (not displayed
here) too, I'd guess. Aside from that:
Acked-by: Paul Bolle <[email protected]>
Paul Bolle
On Sun, 2014-02-09 at 16:54 -0500, Gene Heskett wrote:
> And much of it is in a bad make oldconfig that I can't date, but all of the
> multimedia stuff has been stripped and I can no longer use my pcHDTV3000
> card as just one for instance. I just tested it, using an oldconfig that
> contained several hundred bits and pieces under the ATSC & DVB headers,
> after the oldconfig was done, all that was stripped from the new one, every
> trace of it. That was working code guys, what the hell? Kconfig could
> have problems, but the oldconfig output being stripped is a much larger
> one. First problems first. Then you can really see how fubared kconfig
> is.
What has this got to do with an invalid Kconfig dependency in
arch/mn10300?
Paul Bolle
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> 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.
> 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(-)
>
> [..]
>
> diff --git a/drivers/video/mmp/hw/Kconfig b/drivers/video/mmp/hw/Kconfig
> index 57b03e2..95e8ec2 100644
> --- a/drivers/video/mmp/hw/Kconfig
> +++ b/drivers/video/mmp/hw/Kconfig
> @@ -2,7 +2,7 @@ if MMP_DISP
>
> config MMP_DISP_CONTROLLER
> bool "mmp display controller hw support"
> - depends on CPU_PXA910 || CPU_MMP2 || CPU_PXA988
> + depends on CPU_PXA910 || CPU_MMP2
> default n
> help
> Marvell MMP display hw controller support
Please also remove the reference to PXA988 in the help text. Aside from
that:
Acked-by: Paul Bolle <[email protected]>
Paul Bolle
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
Orphaned a year ago, see commit 060f3043e5e ("ARM: smp: Remove local
timer API"). But this one got added after that, in the same relase
cycle.
> Signed-off-by: Richard Weinberger <[email protected]>
This gets my
Acked-by: Paul Bolle <[email protected]>
as it's correct (we're dropping a nop) but I'd appreciate it if you'd
resend with the above info added. That would easy review by others too.
Paul Bolle
> arch/arm/mach-shmobile/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 3386406..c055388 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -8,7 +8,6 @@ config ARCH_SHMOBILE_MULTI
> select CPU_V7
> select GENERIC_CLOCKEVENTS
> select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if LOCAL_TIMERS
> select HAVE_SMP
> select ARM_GIC
> select MIGHT_HAVE_CACHE_L2X0
On Sunday 09 February 2014, Paul Bolle wrote:
>On Sun, 2014-02-09 at 16:54 -0500, Gene Heskett wrote:
>> And much of it is in a bad make oldconfig that I can't date, but all of
>> the multimedia stuff has been stripped and I can no longer use my
>> pcHDTV3000 card as just one for instance. I just tested it, using an
>> oldconfig that contained several hundred bits and pieces under the
>> ATSC & DVB headers, after the oldconfig was done, all that was
>> stripped from the new one, every trace of it. That was working code
>> guys, what the hell? Kconfig could have problems, but the oldconfig
>> output being stripped is a much larger one. First problems first.
>> Then you can really see how fubared kconfig is.
>
>What has this got to do with an invalid Kconfig dependency in
>arch/mn10300?
>
>
>Paul Bolle
Probably not much Paul,I was trying to point out a much bigger problem for
many of us at least on the x86 machinery, who seem to have accepted that
support of their machinery has now apparently been deprecated, by something
in the make oldconfig region. The arch/mn10300 problem is completely lost
in the noise of this breakage to the x86 people. And I dare say there are
more of us by a factor of at least 100.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On Sun, 2014-02-09 at 17:41 -0500, Gene Heskett wrote:
> On Sunday 09 February 2014, Paul Bolle wrote:
> >What has this got to do with an invalid Kconfig dependency in
> >arch/mn10300?
>
> Probably not much
Feel free to open a new thread, with the relevant details, and involve
the relevant people and lists. I have no idea what you're going on about
and could not care less (in the context of this thread).
Paul Bolle
On Sun, 2014-02-09 at 19:48 +0100, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Merge with 26/28? Anyhow, my comments are basically identical to those
on that patch. So:
Acked-by: Paul Bolle <[email protected]>
Paul Bolle
> arch/arm/mach-omap2/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 653b489..2817f1f 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -54,7 +54,6 @@ config SOC_OMAP5
> select ARM_GIC
> select CPU_V7
> select HAVE_ARM_SCU if SMP
> - select HAVE_ARM_TWD if LOCAL_TIMERS
> select HAVE_SMP
> select HAVE_ARM_ARCH_TIMER
> select ARM_ERRATA_798181 if SMP
On Sunday 09 February 2014, Paul Bolle wrote:
>On Sun, 2014-02-09 at 17:41 -0500, Gene Heskett wrote:
>> On Sunday 09 February 2014, Paul Bolle wrote:
>> >What has this got to do with an invalid Kconfig dependency in
>> >arch/mn10300?
>>
>> Probably not much
>
>Feel free to open a new thread, with the relevant details, and involve
>the relevant people and lists. I have no idea what you're going on about
>and could not care less (in the context of this thread).
>
>
>Paul Bolle
Been tried, got zero response. Frankly, posting just to lkml, hoping the
revalent people see it, is beginning to act like posting to a black hole.
Somewhere between 3.4.36 and 3.8.2, 99% of it disappeared from an oldconfig
output. I don't have any trees between those two on my machine or I'd pin
it down a little more specifically.
So who would the correct maintainer person be, for such as a "make
oldconfig"?
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On 02/09/2014 01:38 PM, Richard Weinberger wrote:
> Am 09.02.2014 22:35, schrieb Guenter Roeck:
>> I could understand if you would replace DEPRECATED with BROKEN,
>> but causing a potentially large number of broken builds and
>> then leave it to others to clean up the resulting mess doesn't
>> make any sense to me and should, in my opinion, be rejected.
>
> Currently the mess is hidden by bad Kconfig dependencies.
> We have to face it. :)
>
You can make the breakage obvious by using BROKEN instead
of DEPRECATED. Then it can be fixed.
Otherwise you could, using your logic, remove all BROKEN
dependencies as well (all 90 or so of them). That symbol,
after all, is just as orphan as DEPRECATED.
The point here is to not unnecessarily introduce build problems.
There are people out there trying to ensure that no new build
breakages are introduced. By making X configurations
non-buildable, all you accomplish is to ensure that no one will
be able to discover real new build problems anymore, because
those new problems will all disappear in the build breakage
noise you introduced.
So, in practice, all you accomplish is to make the kernel
less maintainable. If that is your goal, mission accomplished.
Otherwise I would kindly ask you to reconsider.
Note that I would not mind some big cleanup effort to simply
remove all code marked as BROKEN, and I would be more than
happy to assist in such an effort.
However, breaking builds on purpose in the hope that someone
would magically show up and fix it is just plain wrong.
Note that I do not refer to a specific platform.
Guenter
On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> [PATCH 14/28] Remove MACH_SMDKC210
Did this one make it to lkml?
Anyhow, you should also check MACH_SMDKV310. And then have a look at
https://lkml.org/lkml/2013/7/14/27 , in which Mark Brown (added in CC)
and I spent some time not understanding each other (at least, that was
my impression).
Paul Bolle
Thanks.
Acked-by: Lennox Wu <[email protected]>
2014-02-10 2:47 GMT+08:00 Richard Weinberger <[email protected]>:
> 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(-)
>
> diff --git a/arch/score/Kconfig b/arch/score/Kconfig
> index c75d06a..c7a7b65 100644
> --- a/arch/score/Kconfig
> +++ b/arch/score/Kconfig
> @@ -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
>
On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
> On Sunday 09 February 2014, Paul Bolle wrote:
> >
> >Feel free to open a new thread, with the relevant details, and involve
> >the relevant people and lists. I have no idea what you're going on about
> >and could not care less (in the context of this thread).
> >
> >
> >Paul Bolle
>
> Been tried, got zero response. Frankly, posting just to lkml, hoping the
> revalent people see it, is beginning to act like posting to a black hole.
>
I saw one response to you, from Randy Dunlap, asking for more
information : https://lkml.org/lkml/2014/2/8/153
After your posts a few days ago, I'm tempted to suggest you check
your spam filters, and also any mail files your virus scanner might
have quarantined. But it is also possible that you just haven't
received it - email is like that.
ĸen
--
das eine Mal als Tragödie, dieses Mal als Farce
On 02/09/2014 07:07 PM, Ken Moffat wrote:
> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>
>>> Feel free to open a new thread, with the relevant details, and involve
>>> the relevant people and lists. I have no idea what you're going on about
>>> and could not care less (in the context of this thread).
>>>
>>>
>>> Paul Bolle
>>
>> Been tried, got zero response. Frankly, posting just to lkml, hoping the
>> revalent people see it, is beginning to act like posting to a black hole.
>>
> I saw one response to you, from Randy Dunlap, asking for more
> information : https://lkml.org/lkml/2014/2/8/153
wow, I don't know how I saw this message (thanks, Ken),
but replying to this patch was NOT the right thing to do, Gene.
Just reply to my request and I'll be glad to look into it.
> After your posts a few days ago, I'm tempted to suggest you check
> your spam filters, and also any mail files your virus scanner might
> have quarantined. But it is also possible that you just haven't
> received it - email is like that.
>
> ĸen
--
~Randy
On Sunday 09 February 2014, Randy Dunlap wrote:
>On 02/09/2014 07:07 PM, Ken Moffat wrote:
>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>> Feel free to open a new thread, with the relevant details, and
>>>> involve the relevant people and lists. I have no idea what you're
>>>> going on about and could not care less (in the context of this
>>>> thread).
>>>>
>>>>
>>>> Paul Bolle
>>>
>>> Been tried, got zero response. Frankly, posting just to lkml, hoping
>>> the revalent people see it, is beginning to act like posting to a
>>> black hole.
>>>
>> I saw one response to you, from Randy Dunlap, asking for more
>>
>> information : https://lkml.org/lkml/2014/2/8/153
>
>wow, I don't know how I saw this message (thanks, Ken),
>but replying to this patch was NOT the right thing to do, Gene.
>
>Just reply to my request and I'll be glad to look into it.
>
>> After your posts a few days ago, I'm tempted to suggest you check
>>
>> your spam filters, and also any mail files your virus scanner might
>> have quarantined. But it is also possible that you just haven't
>> received it - email is like that.
>>
>> ĸen
Spam and viri filters watched carefully. I also use mailfilter, and watch
its logs full time for FP's.
And I didn't reply because the question seemed way too broad, almost as if
my lament wasn't read. That and the mail server doesn't like big
attachments. So rather than reply to the list, I'll excise some of the
addresses that bounce from a reply_all or don't like me, and send the
.config from a 3.019 build which seems ok, but by the time that config is
run thru a make oldconfig at 3.8.2, most all the media, ATSC and DVB stuff
is gone. So I'll attach that one too. The later file grew 22kb, but
wholesale parts of the first one are missing from the 2nd.
I've look at Makefile, but most Makefiles are swahili to me so I could be
looking at it and not recognizing it.
Thank you all.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On 02/09/2014 07:46 PM, Gene Heskett wrote:
> On Sunday 09 February 2014, Randy Dunlap wrote:
>> On 02/09/2014 07:07 PM, Ken Moffat wrote:
>>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>>> Feel free to open a new thread, with the relevant details, and
>>>>> involve the relevant people and lists. I have no idea what you're
>>>>> going on about and could not care less (in the context of this
>>>>> thread).
>>>>>
>>>>>
>>>>> Paul Bolle
>>>>
>>>> Been tried, got zero response. Frankly, posting just to lkml, hoping
>>>> the revalent people see it, is beginning to act like posting to a
>>>> black hole.
>>>>
>>> I saw one response to you, from Randy Dunlap, asking for more
>>>
>>> information : https://lkml.org/lkml/2014/2/8/153
>>
>> wow, I don't know how I saw this message (thanks, Ken),
>> but replying to this patch was NOT the right thing to do, Gene.
>>
>> Just reply to my request and I'll be glad to look into it.
>>
>>> After your posts a few days ago, I'm tempted to suggest you check
>>>
>>> your spam filters, and also any mail files your virus scanner might
>>> have quarantined. But it is also possible that you just haven't
>>> received it - email is like that.
>>>
>>> ؤ¸en
>
> Spam and viri filters watched carefully. I also use mailfilter, and watch
> its logs full time for FP's.
Still -- this ATSC problem should not be part of a reply to the Remove DEPRECATED patch.
> And I didn't reply because the question seemed way too broad, almost as if
what question seemed to broad?
> my lament wasn't read. That and the mail server doesn't like big
what mail server? yours? wdtv? vger.kernel.org certainly has no problem with them.
> attachments. So rather than reply to the list, I'll excise some of the
> addresses that bounce from a reply_all or don't like me, and send the
> .config from a 3.019 build which seems ok, but by the time that config is
> run thru a make oldconfig at 3.8.2, most all the media, ATSC and DVB stuff
> is gone. So I'll attach that one too. The later file grew 22kb, but
> wholesale parts of the first one are missing from the 2nd.
Gene, I want to make sure where you are saying the problem is.
Is it going directly from 3.019 to 3.8.2, with no intervening kernel versions?
I don't know what kernel version 3.019 is. Do you mean 3.0.19?
or is that some distro numbering?
>
> I've look at Makefile, but most Makefiles are swahili to me so I could be
> looking at it and not recognizing it.
>
> Thank you all.
>
> Cheers, Gene
>
--
~Randy
On Sunday 09 February 2014, Randy Dunlap wrote:
>On 02/09/2014 07:46 PM, Gene Heskett wrote:
>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>> On 02/09/2014 07:07 PM, Ken Moffat wrote:
>>>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>>>> Feel free to open a new thread, with the relevant details, and
>>>>>> involve the relevant people and lists. I have no idea what you're
>>>>>> going on about and could not care less (in the context of this
>>>>>> thread).
>>>>>>
>>>>>>
>>>>>> Paul Bolle
>>>>>
>>>>> Been tried, got zero response. Frankly, posting just to lkml,
>>>>> hoping the revalent people see it, is beginning to act like posting
>>>>> to a black hole.
>>>>>
>>>> I saw one response to you, from Randy Dunlap, asking for more
>>>>
>>>> information : https://lkml.org/lkml/2014/2/8/153
>>>
>>> wow, I don't know how I saw this message (thanks, Ken),
>>> but replying to this patch was NOT the right thing to do, Gene.
>>>
>>> Just reply to my request and I'll be glad to look into it.
>>>
>>>> After your posts a few days ago, I'm tempted to suggest you check
>>>>
>>>> your spam filters, and also any mail files your virus scanner might
>>>> have quarantined. But it is also possible that you just haven't
>>>> received it - email is like that.
>>>>
>>>> ؤ¸en
>>
>> Spam and viri filters watched carefully. I also use mailfilter, and
>> watch its logs full time for FP's.
>
>Still -- this ATSC problem should not be part of a reply to the Remove
>DEPRECATED patch.
True. But I got some attention.
>> And I didn't reply because the question seemed way too broad, almost as
>> if
>
>what question seemed to broad?
You wanted to see "a" config, but I wanted to show the diffs. Also
yesterday I hadn't gone thru what I have yet to see where it falls apart.
>
>> my lament wasn't read. That and the mail server doesn't like big
>
>what mail server? yours? wdtv? vger.kernel.org certainly has no
>problem with them.
I have gotten bounced from lkml because a screen shot pix of a failed boot
was too big. Perhaps 18 months or so. It was big, from a 10 megapixel
camera.
>> attachments. So rather than reply to the list, I'll excise some of the
>> addresses that bounce from a reply_all or don't like me, and send the
>> .config from a 3.019 build which seems ok, but by the time that config
>> is run thru a make oldconfig at 3.8.2, most all the media, ATSC and
>> DVB stuff is gone. So I'll attach that one too. The later file grew
>> 22kb, but wholesale parts of the first one are missing from the 2nd.
>
>Gene, I want to make sure where you are saying the problem is.
>Is it going directly from 3.019 to 3.8.2, with no intervening kernel
>versions?
No, one intermediate step in this case.
I started with 3.0.19, which was fine, took that one to 3.2.40, and that
one to 3.8.2 because I don't have anything between those here. Not exactly
a step by step.
>I don't know what kernel version 3.019 is. Do you mean 3.0.19?
Yes, Joanne Dow would call that a typu for sure.
Thanks Randy.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On 02/09/2014 08:14 PM, Gene Heskett wrote:
> On Sunday 09 February 2014, Randy Dunlap wrote:
>> On 02/09/2014 07:46 PM, Gene Heskett wrote:
>>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>>> On 02/09/2014 07:07 PM, Ken Moffat wrote:
>>>>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>>>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>>>>> Feel free to open a new thread, with the relevant details, and
>>>>>>> involve the relevant people and lists. I have no idea what you're
>>>>>>> going on about and could not care less (in the context of this
>>>>>>> thread).
>>>>>>>
>>>>>>>
>>>>>>> Paul Bolle
>>>>>>
>>>>>> Been tried, got zero response. Frankly, posting just to lkml,
>>>>>> hoping the revalent people see it, is beginning to act like posting
>>>>>> to a black hole.
>>>>>>
>>>>> I saw one response to you, from Randy Dunlap, asking for more
>>>>>
>>>>> information : https://lkml.org/lkml/2014/2/8/153
>>>>
>>>> wow, I don't know how I saw this message (thanks, Ken),
>>>> but replying to this patch was NOT the right thing to do, Gene.
>>>>
>>>> Just reply to my request and I'll be glad to look into it.
>>>>
>>>>> After your posts a few days ago, I'm tempted to suggest you check
>>>>>
>>>>> your spam filters, and also any mail files your virus scanner might
>>>>> have quarantined. But it is also possible that you just haven't
>>>>> received it - email is like that.
>>>>>
>>>>> ؤ¸en
>>>
>>> Spam and viri filters watched carefully. I also use mailfilter, and
>>> watch its logs full time for FP's.
>>
>> Still -- this ATSC problem should not be part of a reply to the Remove
>> DEPRECATED patch.
>
> True. But I got some attention.
>
>>> And I didn't reply because the question seemed way too broad, almost as
>>> if
>>
>> what question seemed to broad?
>
> You wanted to see "a" config, but I wanted to show the diffs. Also
> yesterday I hadn't gone thru what I have yet to see where it falls apart.
>>
>>> my lament wasn't read. That and the mail server doesn't like big
>>
>> what mail server? yours? wdtv? vger.kernel.org certainly has no
>> problem with them.
>
> I have gotten bounced from lkml because a screen shot pix of a failed boot
> was too big. Perhaps 18 months or so. It was big, from a 10 megapixel
> camera.
>
>>> attachments. So rather than reply to the list, I'll excise some of the
>>> addresses that bounce from a reply_all or don't like me, and send the
>>> .config from a 3.019 build which seems ok, but by the time that config
>>> is run thru a make oldconfig at 3.8.2, most all the media, ATSC and
>>> DVB stuff is gone. So I'll attach that one too. The later file grew
>>> 22kb, but wholesale parts of the first one are missing from the 2nd.
>>
>> Gene, I want to make sure where you are saying the problem is.
>> Is it going directly from 3.019 to 3.8.2, with no intervening kernel
>> versions?
>
> No, one intermediate step in this case.
>
> I started with 3.0.19, which was fine, took that one to 3.2.40, and that
> one to 3.8.2 because I don't have anything between those here. Not exactly
> a step by step.
and when you go from one kernel version to the next, do you use
$ make oldconfig
and answer all of its questions, or do you use
$ yes '' | make oldconfig
or some other variant? (I guess in your super build script.)
>> I don't know what kernel version 3.019 is. Do you mean 3.0.19?
>
> Yes, Joanne Dow would call that a typu for sure.
>
> Thanks Randy.
>
> Cheers, Gene
>
--
~Randy
On Sunday 09 February 2014, Randy Dunlap wrote:
>On 02/09/2014 08:14 PM, Gene Heskett wrote:
>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>> On 02/09/2014 07:46 PM, Gene Heskett wrote:
>>>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>>>> On 02/09/2014 07:07 PM, Ken Moffat wrote:
>>>>>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>>>>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>>>>>> Feel free to open a new thread, with the relevant details, and
>>>>>>>> involve the relevant people and lists. I have no idea what you're
>>>>>>>> going on about and could not care less (in the context of this
>>>>>>>> thread).
>>>>>>>>
>>>>>>>>
>>>>>>>> Paul Bolle
>>>>>>>
>>>>>>> Been tried, got zero response. Frankly, posting just to lkml,
>>>>>>> hoping the revalent people see it, is beginning to act like
>>>>>>> posting to a black hole.
>>>>>>>
>>>>>> I saw one response to you, from Randy Dunlap, asking for more
>>>>>>
>>>>>> information : https://lkml.org/lkml/2014/2/8/153
>>>>>
>>>>> wow, I don't know how I saw this message (thanks, Ken),
>>>>> but replying to this patch was NOT the right thing to do, Gene.
>>>>>
>>>>> Just reply to my request and I'll be glad to look into it.
>>>>>
>>>>>> After your posts a few days ago, I'm tempted to suggest you check
>>>>>>
>>>>>> your spam filters, and also any mail files your virus scanner might
>>>>>> have quarantined. But it is also possible that you just haven't
>>>>>> received it - email is like that.
>>>>>>
>>>>>> ؤ¸en
>>>>
>>>> Spam and viri filters watched carefully. I also use mailfilter, and
>>>> watch its logs full time for FP's.
>>>
>>> Still -- this ATSC problem should not be part of a reply to the Remove
>>> DEPRECATED patch.
>>
>> True. But I got some attention.
>>
>>>> And I didn't reply because the question seemed way too broad, almost
>>>> as if
>>>
>>> what question seemed to broad?
>>
>> You wanted to see "a" config, but I wanted to show the diffs. Also
>> yesterday I hadn't gone thru what I have yet to see where it falls
>> apart.
>>
>>>> my lament wasn't read. That and the mail server doesn't like big
>>>
>>> what mail server? yours? wdtv? vger.kernel.org certainly has no
>>> problem with them.
>>
>> I have gotten bounced from lkml because a screen shot pix of a failed
>> boot was too big. Perhaps 18 months or so. It was big, from a 10
>> megapixel camera.
>>
>>>> attachments. So rather than reply to the list, I'll excise some of
>>>> the addresses that bounce from a reply_all or don't like me, and
>>>> send the .config from a 3.019 build which seems ok, but by the time
>>>> that config is run thru a make oldconfig at 3.8.2, most all the
>>>> media, ATSC and DVB stuff is gone. So I'll attach that one too.
>>>> The later file grew 22kb, but wholesale parts of the first one are
>>>> missing from the 2nd.
>>>
>>> Gene, I want to make sure where you are saying the problem is.
>>> Is it going directly from 3.019 to 3.8.2, with no intervening kernel
>>> versions?
>>
>> No, one intermediate step in this case.
>>
>> I started with 3.0.19, which was fine, took that one to 3.2.40, and
>> that one to 3.8.2 because I don't have anything between those here.
>> Not exactly a step by step.
>
>and when you go from one kernel version to the next, do you use
>
>$ make oldconfig
>and answer all of its questions, or do you use
I generally answer all its questions, or take the default by hitting enter,
but I do read all its questions.
>$ yes '' | make oldconfig
Never done that in all these years.
>or some other variant? (I guess in your super build script.)
This is long before my "super script" gets fired off.
And that part is actually working well, run it as root, do a grub-update
and reboot.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
+cc linux-samsung-soc list
On 10 February 2014 01:38, Paul Bolle <[email protected]> wrote:
> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
>> 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(-)
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index 79bbc21..20d062d 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -178,7 +178,7 @@ config TEGRA_IOMMU_SMMU
>>
>> 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).
Please refer to some on-going discussion about it at [1].
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/26842
--
With warm regards,
Sachin
Hi Richard,
On Monday 10 February 2014 12:18 AM, Richard Weinberger wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Thanks for the cleanup. Applied to ARC for-next.
-Vineet
> ---
> arch/arc/plat-arcfpga/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arc/plat-arcfpga/Kconfig b/arch/arc/plat-arcfpga/Kconfig
> index 295cefe..33058aa 100644
> --- a/arch/arc/plat-arcfpga/Kconfig
> +++ b/arch/arc/plat-arcfpga/Kconfig
> @@ -33,7 +33,6 @@ config ISS_SMP_EXTN
> bool "ARC SMP Extensions (ISS Models only)"
> default n
> depends on SMP
> - select ARC_HAS_COH_RTSC
> help
> SMP Extensions to ARC700, in a "simulation only" Model, supported in
> ARC ISS (Instruction Set Simulator).
Hi Paul,
On Monday 10 February 2014 01:16 AM, Paul Bolle wrote:
>> The symbol is an orphan, get rid of it.
>> >
>> > Signed-off-by: Richard Weinberger <[email protected]>
> Acked-by: Paul Bolle <[email protected]>
>
> This Kconfig symbol was removed in commit 7d087a54aed ("ARC: [SMP]
> Disallow RTSC"), merged in v3.13.
>
I've applied you ACK, with the fixed commit-id 7d0857a54aed
Thx,
-Vineet
On 02/09/2014 08:32 PM, Gene Heskett wrote:
> On Sunday 09 February 2014, Randy Dunlap wrote:
>> On 02/09/2014 08:14 PM, Gene Heskett wrote:
>>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>>> On 02/09/2014 07:46 PM, Gene Heskett wrote:
>>>>> On Sunday 09 February 2014, Randy Dunlap wrote:
>>>>>> On 02/09/2014 07:07 PM, Ken Moffat wrote:
>>>>>>> On Sun, Feb 09, 2014 at 06:05:41PM -0500, Gene Heskett wrote:
>>>>>>>> On Sunday 09 February 2014, Paul Bolle wrote:
>>>>>>>>> Feel free to open a new thread, with the relevant details, and
>>>>>>>>> involve the relevant people and lists. I have no idea what you're
>>>>>>>>> going on about and could not care less (in the context of this
>>>>>>>>> thread).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Paul Bolle
>>>>>>>>
>>>>>>>> Been tried, got zero response. Frankly, posting just to lkml,
>>>>>>>> hoping the revalent people see it, is beginning to act like
>>>>>>>> posting to a black hole.
>>>>>>>>
>>>>>>> I saw one response to you, from Randy Dunlap, asking for more
>>>>>>>
>>>>>>> information : https://lkml.org/lkml/2014/2/8/153
>>>>>>
>>>>>> wow, I don't know how I saw this message (thanks, Ken),
>>>>>> but replying to this patch was NOT the right thing to do, Gene.
>>>>>>
>>>>>> Just reply to my request and I'll be glad to look into it.
>>>>>>
>>>>>>> After your posts a few days ago, I'm tempted to suggest you check
>>>>>>>
>>>>>>> your spam filters, and also any mail files your virus scanner might
>>>>>>> have quarantined. But it is also possible that you just haven't
>>>>>>> received it - email is like that.
>>>>>>>
>>>>>>> ط¤آ¸en
>>>>>
>>>>> Spam and viri filters watched carefully. I also use mailfilter, and
>>>>> watch its logs full time for FP's.
>>>>
>>>> Still -- this ATSC problem should not be part of a reply to the Remove
>>>> DEPRECATED patch.
>>>
>>> True. But I got some attention.
>>>
>>>>> And I didn't reply because the question seemed way too broad, almost
>>>>> as if
>>>>
>>>> what question seemed to broad?
>>>
>>> You wanted to see "a" config, but I wanted to show the diffs. Also
>>> yesterday I hadn't gone thru what I have yet to see where it falls
>>> apart.
>>>
>>>>> my lament wasn't read. That and the mail server doesn't like big
>>>>
>>>> what mail server? yours? wdtv? vger.kernel.org certainly has no
>>>> problem with them.
>>>
>>> I have gotten bounced from lkml because a screen shot pix of a failed
>>> boot was too big. Perhaps 18 months or so. It was big, from a 10
>>> megapixel camera.
>>>
>>>>> attachments. So rather than reply to the list, I'll excise some of
>>>>> the addresses that bounce from a reply_all or don't like me, and
>>>>> send the .config from a 3.019 build which seems ok, but by the time
>>>>> that config is run thru a make oldconfig at 3.8.2, most all the
>>>>> media, ATSC and DVB stuff is gone. So I'll attach that one too.
>>>>> The later file grew 22kb, but wholesale parts of the first one are
>>>>> missing from the 2nd.
>>>>
>>>> Gene, I want to make sure where you are saying the problem is.
>>>> Is it going directly from 3.019 to 3.8.2, with no intervening kernel
>>>> versions?
>>>
>>> No, one intermediate step in this case.
>>>
>>> I started with 3.0.19, which was fine, took that one to 3.2.40, and
>>> that one to 3.8.2 because I don't have anything between those here.
>>> Not exactly a step by step.
>>
>> and when you go from one kernel version to the next, do you use
>>
>> $ make oldconfig
>> and answer all of its questions, or do you use
>
> I generally answer all its questions, or take the default by hitting enter,
> but I do read all its questions.
>
>> $ yes '' | make oldconfig
>
> Never done that in all these years.
>
>> or some other variant? (I guess in your super build script.)
>
> This is long before my "super script" gets fired off.
>
> And that part is actually working well, run it as root, do a grub-update
> and reboot.
>
> Cheers, Gene
>
You need to have a Kconfig symbol named DVB_CORE enabled.
In 3.8.2 (and likely previously, but not in 3.2.40),
DVB_CORE depends on having both MEDIA_SUPPORT and MEDIA_DIGITAL_TV_SUPPORT
enabled. Your .confile file has MEDIA_SUPPORT enabled but not
MEDIA_DIGITAL_TV_SUPPORT.
In your 3.2.40 kernel source tree, just edit your .config file and delete the line
that says:
# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
then run [1]
$ make oldconfig
and it will ask you how to set the Kconfig symbol. Tell it 'y'.
and if you can find this line in your .config file:
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
delete it. Run 'make oldconfig' again if you did so at [1] above.
For this Kconfig question:
Autoselect tuners and i2c modules to build (MEDIA_SUBDRV_AUTOSELECT),
answer N.
Then you can select all of the tuners and frontends that you want.
There are LOTS of them to choose from.
IIRC, this all happened because someone decided that they could make the AUTOSELECT
driver feature Better! ugh.
Good luck. Let me know if you need more guidance.
--
~Randy
On Sun, Feb 9, 2014 at 9:21 PM, Richard Weinberger <[email protected]> wrote:
> Am 09.02.2014 21:15, schrieb Paul Bolle:
>> On Sun, 2014-02-09 at 21:04 +0100, Richard Weinberger wrote:
>>> Am 09.02.2014 20:38, schrieb Paul Bolle:
>>>> But now you've enabled a lot of stuff that, as far as I can tell, could
>>>> not have been built since v2.6.39.
>>>
>>> This is by design. If the code does not build/work it needs to be fixed or removed.
>>
>> If that was the design goal of this patch (and similar patches you've
>> sent) it would have been proper to at least say a few words along those
>> lines in the commit explanation.
>
> I assumed that every kernel developer is aware of that fact that unreachable/dead code
> should be removed.
Yes, it should be removed.
But that's not what you did. You did the Kconfig-equivalent of removing a
"#if 0" in a C source file, which causes havoc.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Am 10.02.2014 09:49, schrieb Geert Uytterhoeven:
> On Sun, Feb 9, 2014 at 9:21 PM, Richard Weinberger <[email protected]> wrote:
>> Am 09.02.2014 21:15, schrieb Paul Bolle:
>>> On Sun, 2014-02-09 at 21:04 +0100, Richard Weinberger wrote:
>>>> Am 09.02.2014 20:38, schrieb Paul Bolle:
>>>>> But now you've enabled a lot of stuff that, as far as I can tell, could
>>>>> not have been built since v2.6.39.
>>>>
>>>> This is by design. If the code does not build/work it needs to be fixed or removed.
>>>
>>> If that was the design goal of this patch (and similar patches you've
>>> sent) it would have been proper to at least say a few words along those
>>> lines in the commit explanation.
>>
>> I assumed that every kernel developer is aware of that fact that unreachable/dead code
>> should be removed.
>
> Yes, it should be removed.
>
> But that's not what you did. You did the Kconfig-equivalent of removing a
> "#if 0" in a C source file, which causes havoc.
Fair point. I'll remove that code in v2.
Hopefully I can catch all breakage on my testbed as many archs/configs are involved.
Thanks,
//richard
On Monday 10 February 2014, Randy Dunlap wrote:
[...]
>>>>> Gene, I want to make sure where you are saying the problem is.
>>>>> Is it going directly from 3.019 to 3.8.2, with no intervening kernel
>>>>> versions?
>>>>
>>>> No, one intermediate step in this case.
>>>>
>>>> I started with 3.0.19, which was fine, took that one to 3.2.40, and
>>>> that one to 3.8.2 because I don't have anything between those here.
>>>> Not exactly a step by step.
>>>
>>> and when you go from one kernel version to the next, do you use
>>>
>>> $ make oldconfig
>>> and answer all of its questions, or do you use
>>
>> I generally answer all its questions, or take the default by hitting
>> enter, but I do read all its questions.
>>
>>> $ yes '' | make oldconfig
>>
>> Never done that in all these years.
>>
>>> or some other variant? (I guess in your super build script.)
>>
>> This is long before my "super script" gets fired off.
>>
>> And that part is actually working well, run it as root, do a
>> grub-update and reboot.
>>
>> Cheers, Gene
>
>You need to have a Kconfig symbol named DVB_CORE enabled.
>
>In 3.8.2 (and likely previously, but not in 3.2.40),
>DVB_CORE depends on having both MEDIA_SUPPORT and
>MEDIA_DIGITAL_TV_SUPPORT enabled. Your .confile file has MEDIA_SUPPORT
>enabled but not
>MEDIA_DIGITAL_TV_SUPPORT.
>
>In your 3.2.40 kernel source tree, just edit your .config file and delete
>the line that says:
># CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
>
>then run [1]
>$ make oldconfig
>and it will ask you how to set the Kconfig symbol. Tell it 'y'.
>
>and if you can find this line in your .config file:
>CONFIG_MEDIA_SUBDRV_AUTOSELECT=y
>
>delete it. Run 'make oldconfig' again if you did so at [1] above.
>For this Kconfig question:
> Autoselect tuners and i2c modules to build (MEDIA_SUBDRV_AUTOSELECT),
>answer N.
>Then you can select all of the tuners and frontends that you want.
>There are LOTS of them to choose from.
>
>IIRC, this all happened because someone decided that they could make the
>AUTOSELECT driver feature Better! ugh.
>
>Good luck. Let me know if you need more guidance.
Printed. That sounds as if I ought to be able to do it, which I will take a
shot at tomorrow.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On Mon, Feb 10, 2014 at 01:58:40AM +0100, Paul Bolle wrote:
> Anyhow, you should also check MACH_SMDKV310. And then have a look at
> https://lkml.org/lkml/2013/7/14/27 , in which Mark Brown (added in CC)
> and I spent some time not understanding each other (at least, that was
> my impression).
I understand what you were doing, you just haven't thought about what
what you're doing - why the code is that way and what actually needs to
be done to it? You didn't reply to my last mail there...
2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
> 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 <[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.
>
> 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
--
BR,
Sergey
Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
>> 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 <[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.
>>
>> 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.
--
Regards,
Oleksij
2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:
> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
>>> 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 <[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.
>>>
>>> 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.
--
BR,
Sergey
On Mon, 2014-02-10 at 11:00 +0000, Mark Brown wrote:
> You didn't reply to my last mail there...
Because I feared we'd ended up in a loop, where we both repeat our
statements. I seem to remember getting in such a loop with you,
regarding another patch, and it wasn't productive. But I'll start again
in the thread regarding Richard's patch 14/28 and see if things work out
better this time.
Paul Bolle
On Mon, 2014-02-10 at 10:05 +0530, Vineet Gupta wrote:
> On Monday 10 February 2014 01:16 AM, Paul Bolle wrote:
> > This Kconfig symbol was removed in commit 7d087a54aed ("ARC: [SMP]
> > Disallow RTSC"), merged in v3.13.
>
> I've applied you ACK, with the fixed commit-id 7d0857a54aed
Manually trimming 40 hex digits down to 12 digits. What can go wrong?
Thanks!
Paul Bolle
On Monday 10 February 2014 07:18 PM, Paul Bolle wrote:
> On Mon, 2014-02-10 at 10:05 +0530, Vineet Gupta wrote:
>> On Monday 10 February 2014 01:16 AM, Paul Bolle wrote:
>>> This Kconfig symbol was removed in commit 7d087a54aed ("ARC: [SMP]
>>> Disallow RTSC"), merged in v3.13.
>> I've applied you ACK, with the fixed commit-id 7d0857a54aed
> Manually trimming 40 hex digits down to 12 digits. What can go wrong?
Yes pretty weird - one intermediate char got eaten somehow.
Richard Weinberger <[email protected]> wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
Acked-by: David Howells <[email protected]>
On Mon, 2014-02-10 at 14:06 +0000, Vineet Gupta wrote:
> > Manually trimming 40 hex digits down to 12 digits. What can go wrong?
>
> Yes pretty weird - one intermediate char got eaten somehow.
I know exactly what happened.
See, I can't reliably count to twelve. But I can chop of (say) four
digits at a time by inserting a space and throw away the last 28 digits.
I then will have three set of four digits. And, being an editing genius,
merging these three sets will, every now and then, give me a string of
eleven digits!
Perhaps I should write a vim macro to do all this for me.
Paul Bolle
On Monday 10 February 2014, Randy Dunlap wrote:
>On 02/09/2014 08:32 PM, Gene Heskett wrote:
>AUTOSELECT driver feature Better! ugh.
Spit. I presume geneology discussions are off topic. :)
>
>Good luck. Let me know if you need more guidance.
Hat in hand, I figured I had better get the first one that fails, 3.2.40,
to work before I carried that fwd to a more current kernel, but 5 or 6
builds & boot failure later I am stumped.
The boot gets to top_init, reports the / drive is unavailable and it cannot
load /lib/modules/3.2.40/modules.dep, which does exist.
Stops, times out in about a minute and falls thru to the busybox shell, and
of course my keyboard and mouse are wireless to usb, so neither work, reset
button tap time.
The only reason I can deduce is that because the drive isn't mounted,
something is still missing, either in the vmlinuz file or in the initrd
file.
This most working 3.12.9 bootup shows:
gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
sata_nv 16890 12
libata 146855 2 pata_amd,sata_nv
And I'm pretty sure all that is in the initrd.
Except according to grep, none of that is in
/lib/modules/3.2.40/modules.dep
And I cannot find anyplace in a make xconfig that mentions libata.
So obviously my .config is still fubared. It does grep in the other
modules.dep files for several other versions.
In fact, no .config I have mentions it. At my age the hair is thinning
quickly enough.
So, Next please? libata is missing, and so is sata_nv in spite of that
being enabled:
gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
CONFIG_SATA_NV=y
But I see thats builtin, but it didn't help.
Thanks all.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:
> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:
>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
>>>> 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 <[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.
>>>>
>>>> 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.
--
Florian
On 02/10/2014 12:21 PM, Gene Heskett wrote:
> On Monday 10 February 2014, Randy Dunlap wrote:
>> On 02/09/2014 08:32 PM, Gene Heskett wrote:
>> AUTOSELECT driver feature Better! ugh.
>
> Spit. I presume geneology discussions are off topic. :)
>>
>> Good luck. Let me know if you need more guidance.
>
> Hat in hand, I figured I had better get the first one that fails, 3.2.40,
> to work before I carried that fwd to a more current kernel, but 5 or 6
> builds & boot failure later I am stumped.
>
> The boot gets to top_init, reports the / drive is unavailable and it cannot
> load /lib/modules/3.2.40/modules.dep, which does exist.
>
> Stops, times out in about a minute and falls thru to the busybox shell, and
> of course my keyboard and mouse are wireless to usb, so neither work, reset
> button tap time.
>
> The only reason I can deduce is that because the drive isn't mounted,
> something is still missing, either in the vmlinuz file or in the initrd
> file.
>
> This most working 3.12.9 bootup shows:
>
> gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
> sata_nv 16890 12
> libata 146855 2 pata_amd,sata_nv
>
> And I'm pretty sure all that is in the initrd.
>
> Except according to grep, none of that is in
> /lib/modules/3.2.40/modules.dep
>
> And I cannot find anyplace in a make xconfig that mentions libata.
> So obviously my .config is still fubared. It does grep in the other
> modules.dep files for several other versions.
>
> In fact, no .config I have mentions it. At my age the hair is thinning
> quickly enough.
>
> So, Next please? libata is missing, and so is sata_nv in spite of that
> being enabled:
It's missing as a loadable module, but that's OK since it's builtin.
> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
> CONFIG_SATA_NV=y
>
> But I see thats builtin, but it didn't help.
Your .config has (I believe)
CONFIG_ATA=y
and that is what builds libata.
Any other clues?
--
~Randy
2014-02-11 2:37 GMT+04:00 Florian Fainelli <[email protected]>:
> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:
>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:
>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
>>>>> 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 <[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.
>>>>>
>>>>> 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.
--
BR,
Sergey
On Monday 10 February 2014, Randy Dunlap wrote:
>On 02/10/2014 12:21 PM, Gene Heskett wrote:
>> On Monday 10 February 2014, Randy Dunlap wrote:
>>> On 02/09/2014 08:32 PM, Gene Heskett wrote:
>>> AUTOSELECT driver feature Better! ugh.
>>
>> Spit. I presume geneology discussions are off topic. :)
>>
>>> Good luck. Let me know if you need more guidance.
>>
>> Hat in hand, I figured I had better get the first one that fails,
>> 3.2.40, to work before I carried that fwd to a more current kernel,
>> but 5 or 6 builds & boot failure later I am stumped.
>>
>> The boot gets to top_init, reports the / drive is unavailable and it
>> cannot load /lib/modules/3.2.40/modules.dep, which does exist.
>>
>> Stops, times out in about a minute and falls thru to the busybox shell,
>> and of course my keyboard and mouse are wireless to usb, so neither
>> work, reset button tap time.
>>
>> The only reason I can deduce is that because the drive isn't mounted,
>> something is still missing, either in the vmlinuz file or in the initrd
>> file.
>>
>> This most working 3.12.9 bootup shows:
>>
>> gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
>> sata_nv 16890 12
>> libata 146855 2 pata_amd,sata_nv
>>
>> And I'm pretty sure all that is in the initrd.
>>
>> Except according to grep, none of that is in
>> /lib/modules/3.2.40/modules.dep
>>
>> And I cannot find anyplace in a make xconfig that mentions libata.
>> So obviously my .config is still fubared. It does grep in the other
>> modules.dep files for several other versions.
>>
>> In fact, no .config I have mentions it. At my age the hair is thinning
>> quickly enough.
>>
>> So, Next please? libata is missing, and so is sata_nv in spite of that
>
>> being enabled:
>It's missing as a loadable module, but that's OK since it's builtin.
>
>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
>> CONFIG_SATA_NV=y
>>
>> But I see thats builtin, but it didn't help.
>
>Your .config has (I believe)
>CONFIG_ATA=y
>and that is what builds libata.
>
>Any other clues?
Not that I see in the build trace. grepping:
gene@coyote:~/src/linux-3.2.40$ grep CONFIG_ATA .config
CONFIG_ATALK=m
# CONFIG_ATA_OVER_ETH is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
CONFIG_ATA_SFF=y
CONFIG_ATA_BMDMA=y
# CONFIG_ATA_PIIX is not set
CONFIG_ATA_GENERIC=m
And it seems to be building libata:
gene@coyote:~/src/linux-3.2.40/drivers/ata$ ls -l|grep libata|grep .o
-rw-r--r-- 1 root root 10236 2014-02-10 18:19 libata-acpi.o
-rw-rw-r-- 1 gene gene 175870 2013-03-05 22:24 libata-core.c
-rw-r--r-- 1 root root 89616 2014-02-10 18:19 libata-core.o
-rw-r--r-- 1 root root 35904 2014-02-10 18:19 libata-eh.o
-rw-r--r-- 1 root root 222732 2014-02-10 18:19 libata.o
-rw-r--r-- 1 root root 12072 2014-02-10 18:19 libata-pmp.o
-rw-r--r-- 1 root root 37156 2014-02-10 18:19 libata-scsi.o
-rw-r--r-- 1 root root 40996 2014-02-10 18:19 libata-sff.o
-rw-rw-r-- 1 gene gene 19559 2013-03-05 22:24 libata-transport.c
-rw-rw-r-- 1 gene gene 536 2013-03-05 22:24 libata-transport.h
-rw-r--r-- 1 root root 11772 2014-02-10 18:19 libata-transport.o
But libata.ko is not making it into the initrd, nor the modules.dep for
3.2.40.
I been playing 20 monkeys changing one ata related thing at a time & doing
a sudo time -p ./makeit to check, not much use rebooting to check until I
see it.
I'll go gedit .config & change CONFIG_ATA to = m & try one more time.
Got it, test reboot time. Made it 2 lines farther, "switching to clock
source TSC" then fell through to the busybox prompt with all inputs dead.
Sigh.
.config attached if you've got time.
Thanks Randy
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On 02/10/2014 04:13 PM, Gene Heskett wrote:
> On Monday 10 February 2014, Randy Dunlap wrote:
>> On 02/10/2014 12:21 PM, Gene Heskett wrote:
>>> On Monday 10 February 2014, Randy Dunlap wrote:
>>>> On 02/09/2014 08:32 PM, Gene Heskett wrote:
>>>> AUTOSELECT driver feature Better! ugh.
>>>
>>> Spit. I presume geneology discussions are off topic. :)
>>>
>>>> Good luck. Let me know if you need more guidance.
>>>
>>> Hat in hand, I figured I had better get the first one that fails,
>>> 3.2.40, to work before I carried that fwd to a more current kernel,
>>> but 5 or 6 builds & boot failure later I am stumped.
>>>
>>> The boot gets to top_init, reports the / drive is unavailable and it
>>> cannot load /lib/modules/3.2.40/modules.dep, which does exist.
>>>
>>> Stops, times out in about a minute and falls thru to the busybox shell,
>>> and of course my keyboard and mouse are wireless to usb, so neither
>>> work, reset button tap time.
>>>
>>> The only reason I can deduce is that because the drive isn't mounted,
>>> something is still missing, either in the vmlinuz file or in the initrd
>>> file.
>>>
>>> This most working 3.12.9 bootup shows:
>>>
>>> gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
>>> sata_nv 16890 12
>>> libata 146855 2 pata_amd,sata_nv
>>>
>>> And I'm pretty sure all that is in the initrd.
>>>
>>> Except according to grep, none of that is in
>>> /lib/modules/3.2.40/modules.dep
>>>
>>> And I cannot find anyplace in a make xconfig that mentions libata.
>>> So obviously my .config is still fubared. It does grep in the other
>>> modules.dep files for several other versions.
>>>
>>> In fact, no .config I have mentions it. At my age the hair is thinning
>>> quickly enough.
>>>
>>> So, Next please? libata is missing, and so is sata_nv in spite of that
>>
>>> being enabled:
>> It's missing as a loadable module, but that's OK since it's builtin.
>>
>>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
>>> CONFIG_SATA_NV=y
>>>
>>> But I see thats builtin, but it didn't help.
>>
>> Your .config has (I believe)
>> CONFIG_ATA=y
>> and that is what builds libata.
>>
>> Any other clues?
>
> Not that I see in the build trace. grepping:
> gene@coyote:~/src/linux-3.2.40$ grep CONFIG_ATA .config
> CONFIG_ATALK=m
> # CONFIG_ATA_OVER_ETH is not set
> CONFIG_ATA=y
> # CONFIG_ATA_NONSTANDARD is not set
> CONFIG_ATA_VERBOSE_ERROR=y
> CONFIG_ATA_ACPI=y
> CONFIG_ATA_SFF=y
> CONFIG_ATA_BMDMA=y
> # CONFIG_ATA_PIIX is not set
> CONFIG_ATA_GENERIC=m
>
> And it seems to be building libata:
> gene@coyote:~/src/linux-3.2.40/drivers/ata$ ls -l|grep libata|grep .o
> -rw-r--r-- 1 root root 10236 2014-02-10 18:19 libata-acpi.o
> -rw-rw-r-- 1 gene gene 175870 2013-03-05 22:24 libata-core.c
> -rw-r--r-- 1 root root 89616 2014-02-10 18:19 libata-core.o
> -rw-r--r-- 1 root root 35904 2014-02-10 18:19 libata-eh.o
> -rw-r--r-- 1 root root 222732 2014-02-10 18:19 libata.o
> -rw-r--r-- 1 root root 12072 2014-02-10 18:19 libata-pmp.o
> -rw-r--r-- 1 root root 37156 2014-02-10 18:19 libata-scsi.o
> -rw-r--r-- 1 root root 40996 2014-02-10 18:19 libata-sff.o
> -rw-rw-r-- 1 gene gene 19559 2013-03-05 22:24 libata-transport.c
> -rw-rw-r-- 1 gene gene 536 2013-03-05 22:24 libata-transport.h
> -rw-r--r-- 1 root root 11772 2014-02-10 18:19 libata-transport.o
>
> But libata.ko is not making it into the initrd, nor the modules.dep for
> 3.2.40.
Since CONFIG_ATA=y, it's builtin, not a loadable module (.ko), so it won't
be in the initrd or modules.dep.
> I been playing 20 monkeys changing one ata related thing at a time & doing
> a sudo time -p ./makeit to check, not much use rebooting to check until I
> see it.
>
> I'll go gedit .config & change CONFIG_ATA to = m & try one more time.
>
> Got it, test reboot time. Made it 2 lines farther, "switching to clock
> source TSC" then fell through to the busybox prompt with all inputs dead.
>
> Sigh.
>
> .config attached if you've got time.
>
> Thanks Randy
>
> Cheers, Gene
>
I'll look at it Tuesday morning.
--
~Randy
On 02/10/2014 04:13 PM, Gene Heskett wrote:
> On Monday 10 February 2014, Randy Dunlap wrote:
>> On 02/10/2014 12:21 PM, Gene Heskett wrote:
>>> On Monday 10 February 2014, Randy Dunlap wrote:
>>>> On 02/09/2014 08:32 PM, Gene Heskett wrote:
>>>> AUTOSELECT driver feature Better! ugh.
>>>
>>> Spit. I presume geneology discussions are off topic. :)
>>>
>>>> Good luck. Let me know if you need more guidance.
>>>
>>> Hat in hand, I figured I had better get the first one that fails,
>>> 3.2.40, to work before I carried that fwd to a more current kernel,
>>> but 5 or 6 builds & boot failure later I am stumped.
>>>
>>> The boot gets to top_init, reports the / drive is unavailable and it
>>> cannot load /lib/modules/3.2.40/modules.dep, which does exist.
>>>
>>> Stops, times out in about a minute and falls thru to the busybox shell,
>>> and of course my keyboard and mouse are wireless to usb, so neither
>>> work, reset button tap time.
>>>
>>> The only reason I can deduce is that because the drive isn't mounted,
>>> something is still missing, either in the vmlinuz file or in the initrd
>>> file.
>>>
>>> This most working 3.12.9 bootup shows:
>>>
>>> gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
>>> sata_nv 16890 12
>>> libata 146855 2 pata_amd,sata_nv
>>>
>>> And I'm pretty sure all that is in the initrd.
>>>
>>> Except according to grep, none of that is in
>>> /lib/modules/3.2.40/modules.dep
>>>
>>> And I cannot find anyplace in a make xconfig that mentions libata.
>>> So obviously my .config is still fubared. It does grep in the other
>>> modules.dep files for several other versions.
>>>
>>> In fact, no .config I have mentions it. At my age the hair is thinning
>>> quickly enough.
>>>
>>> So, Next please? libata is missing, and so is sata_nv in spite of that
>>
>>> being enabled:
>> It's missing as a loadable module, but that's OK since it's builtin.
>>
>>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
>>> CONFIG_SATA_NV=y
>>>
>>> But I see thats builtin, but it didn't help.
>>
>> Your .config has (I believe)
>> CONFIG_ATA=y
>> and that is what builds libata.
>>
>> Any other clues?
>
> Not that I see in the build trace. grepping:
> gene@coyote:~/src/linux-3.2.40$ grep CONFIG_ATA .config
> CONFIG_ATALK=m
> # CONFIG_ATA_OVER_ETH is not set
> CONFIG_ATA=y
> # CONFIG_ATA_NONSTANDARD is not set
> CONFIG_ATA_VERBOSE_ERROR=y
> CONFIG_ATA_ACPI=y
> CONFIG_ATA_SFF=y
> CONFIG_ATA_BMDMA=y
> # CONFIG_ATA_PIIX is not set
> CONFIG_ATA_GENERIC=m
>
> And it seems to be building libata:
> gene@coyote:~/src/linux-3.2.40/drivers/ata$ ls -l|grep libata|grep .o
> -rw-r--r-- 1 root root 10236 2014-02-10 18:19 libata-acpi.o
> -rw-rw-r-- 1 gene gene 175870 2013-03-05 22:24 libata-core.c
> -rw-r--r-- 1 root root 89616 2014-02-10 18:19 libata-core.o
> -rw-r--r-- 1 root root 35904 2014-02-10 18:19 libata-eh.o
> -rw-r--r-- 1 root root 222732 2014-02-10 18:19 libata.o
> -rw-r--r-- 1 root root 12072 2014-02-10 18:19 libata-pmp.o
> -rw-r--r-- 1 root root 37156 2014-02-10 18:19 libata-scsi.o
> -rw-r--r-- 1 root root 40996 2014-02-10 18:19 libata-sff.o
> -rw-rw-r-- 1 gene gene 19559 2013-03-05 22:24 libata-transport.c
> -rw-rw-r-- 1 gene gene 536 2013-03-05 22:24 libata-transport.h
> -rw-r--r-- 1 root root 11772 2014-02-10 18:19 libata-transport.o
>
> But libata.ko is not making it into the initrd, nor the modules.dep for
> 3.2.40.
>
> I been playing 20 monkeys changing one ata related thing at a time & doing
> a sudo time -p ./makeit to check, not much use rebooting to check until I
> see it.
>
> I'll go gedit .config & change CONFIG_ATA to = m & try one more time.
>
> Got it, test reboot time. Made it 2 lines farther, "switching to clock
> source TSC" then fell through to the busybox prompt with all inputs dead.
>
> Sigh.
>
> .config attached if you've got time.
You have ext[234] filesystems builtin. I suppose the rootfs is one of those?
Your .config file also has the ATA drivers as =m (loadable modules), but
I guess that you also tested with those drivers =y (builtin).
I don't see what the problem is.
You may need to try taking a photo of the failed boot and sending it to
the mailing list (and me) again, even though that has not worked for you
some time in the past.
--
~Randy
+ Ivan, others
On Sun, Feb 09, 2014 at 09:54:02PM +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> > 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(-)
> >
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index 90ff447..a195d57 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
> >
> > 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
On 02/11/2014 09:04 PM, Brian Norris wrote:
> + Ivan, others
>
> On Sun, Feb 09, 2014 at 09:54:02PM +0100, Paul Bolle wrote:
>> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
>>> 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(-)
>>>
>>> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
>>> index 90ff447..a195d57 100644
>>> --- a/drivers/mtd/nand/Kconfig
>>> +++ b/drivers/mtd/nand/Kconfig
>>> @@ -465,7 +465,7 @@ config MTD_NAND_SH_FLCTL
>>>
>>> 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
It is harmless.
For Keystone NAND depends on AEMIF.
AEMIF is responsible to set timings.
In case of Davinci the timings are set by arch/arm/mach-davinci/aemif.c.
In case of Keystone the timings are going to be set by AEMIF driver.
AEMIF is going to be merged I hope. That's plan.
So you can leave it.
--
Regards,
Ivan Khoronzhuk
On Tuesday 11 February 2014, Randy Dunlap wrote:
>
>You have ext[234] filesystems builtin. I suppose the rootfs is one of
>those?
Yes, its all ext2-3-4 here (except swap of course)
>Your .config file also has the ATA drivers as =m (loadable modules), but
>I guess that you also tested with those drivers =y (builtin).
Yes, both ways.
>
>I don't see what the problem is.
>You may need to try taking a photo of the failed boot and sending it to
>the mailing list (and me) again, even though that has not worked for you
>some time in the past.
I'll try it with the ext2-3-4 as modules. But the last error was 2 lines
farther, stalling till the BusyBox timeout after echoing the change to TSC
clock to the low res screen. Whatever that is.
We'll keep plodding along.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On Tuesday 11 February 2014, Randy Dunlap wrote:
>On 02/10/2014 04:13 PM, Gene Heskett wrote:
>> On Monday 10 February 2014, Randy Dunlap wrote:
>>> On 02/10/2014 12:21 PM, Gene Heskett wrote:
>>>> On Monday 10 February 2014, Randy Dunlap wrote:
>>>>> On 02/09/2014 08:32 PM, Gene Heskett wrote:
>>>>> AUTOSELECT driver feature Better! ugh.
>>>>
>>>> Spit. I presume geneology discussions are off topic. :)
>>>>
>>>>> Good luck. Let me know if you need more guidance.
>>>>
>>>> Hat in hand, I figured I had better get the first one that fails,
>>>> 3.2.40, to work before I carried that fwd to a more current kernel,
>>>> but 5 or 6 builds & boot failure later I am stumped.
>>>>
>>>> The boot gets to top_init, reports the / drive is unavailable and it
>>>> cannot load /lib/modules/3.2.40/modules.dep, which does exist.
>>>>
>>>> Stops, times out in about a minute and falls thru to the busybox
>>>> shell, and of course my keyboard and mouse are wireless to usb, so
>>>> neither work, reset button tap time.
>>>>
>>>> The only reason I can deduce is that because the drive isn't mounted,
>>>> something is still missing, either in the vmlinuz file or in the
>>>> initrd file.
>>>>
>>>> This most working 3.12.9 bootup shows:
>>>>
>>>> gene@coyote:~/src/linux-3.2.40$ lsmod |grep sata
>>>> sata_nv 16890 12
>>>> libata 146855 2 pata_amd,sata_nv
>>>>
>>>> And I'm pretty sure all that is in the initrd.
>>>>
>>>> Except according to grep, none of that is in
>>>> /lib/modules/3.2.40/modules.dep
>>>>
>>>> And I cannot find anyplace in a make xconfig that mentions libata.
>>>> So obviously my .config is still fubared. It does grep in the other
>>>> modules.dep files for several other versions.
>>>>
>>>> In fact, no .config I have mentions it. At my age the hair is
>>>> thinning quickly enough.
>>>>
>>>> So, Next please? libata is missing, and so is sata_nv in spite of
>>>> that
>>>
>>>> being enabled:
>>> It's missing as a loadable module, but that's OK since it's builtin.
>>>
>>>> gene@coyote:~/src/linux-3.2.40$ grep SATA_NV .config
>>>> CONFIG_SATA_NV=y
>>>>
>>>> But I see thats builtin, but it didn't help.
>>>
>>> Your .config has (I believe)
>>> CONFIG_ATA=y
>>> and that is what builds libata.
>>>
>>> Any other clues?
>>
>> Not that I see in the build trace. grepping:
>> gene@coyote:~/src/linux-3.2.40$ grep CONFIG_ATA .config
>> CONFIG_ATALK=m
>> # CONFIG_ATA_OVER_ETH is not set
>> CONFIG_ATA=y
>> # CONFIG_ATA_NONSTANDARD is not set
>> CONFIG_ATA_VERBOSE_ERROR=y
>> CONFIG_ATA_ACPI=y
>> CONFIG_ATA_SFF=y
>> CONFIG_ATA_BMDMA=y
>> # CONFIG_ATA_PIIX is not set
>> CONFIG_ATA_GENERIC=m
>>
>> And it seems to be building libata:
>> gene@coyote:~/src/linux-3.2.40/drivers/ata$ ls -l|grep libata|grep .o
>> -rw-r--r-- 1 root root 10236 2014-02-10 18:19 libata-acpi.o
>> -rw-rw-r-- 1 gene gene 175870 2013-03-05 22:24 libata-core.c
>> -rw-r--r-- 1 root root 89616 2014-02-10 18:19 libata-core.o
>> -rw-r--r-- 1 root root 35904 2014-02-10 18:19 libata-eh.o
>> -rw-r--r-- 1 root root 222732 2014-02-10 18:19 libata.o
>> -rw-r--r-- 1 root root 12072 2014-02-10 18:19 libata-pmp.o
>> -rw-r--r-- 1 root root 37156 2014-02-10 18:19 libata-scsi.o
>> -rw-r--r-- 1 root root 40996 2014-02-10 18:19 libata-sff.o
>> -rw-rw-r-- 1 gene gene 19559 2013-03-05 22:24 libata-transport.c
>> -rw-rw-r-- 1 gene gene 536 2013-03-05 22:24 libata-transport.h
>> -rw-r--r-- 1 root root 11772 2014-02-10 18:19 libata-transport.o
>>
>> But libata.ko is not making it into the initrd, nor the modules.dep for
>> 3.2.40.
>>
>> I been playing 20 monkeys changing one ata related thing at a time &
>> doing a sudo time -p ./makeit to check, not much use rebooting to
>> check until I see it.
>>
>> I'll go gedit .config & change CONFIG_ATA to = m & try one more time.
>>
>> Got it, test reboot time. Made it 2 lines farther, "switching to clock
>> source TSC" then fell through to the busybox prompt with all inputs
>> dead.
>>
>> Sigh.
>>
>> .config attached if you've got time.
>
>You have ext[234] filesystems builtin. I suppose the rootfs is one of
>those?
>
>Your .config file also has the ATA drivers as =m (loadable modules), but
>I guess that you also tested with those drivers =y (builtin).
>
>I don't see what the problem is.
>You may need to try taking a photo of the failed boot and sending it to
>the mailing list (and me) again, even though that has not worked for you
>some time in the past.
I thought after sending the last msg, that I would look at the
i386_defconfig to see if I could get a clue about this TSC clock its
mewling about.
It doesn't even exist in either defconfig. ?????
This is 3.12.9 ATM, 3.12.6 will also boot, but I am going to pull that
defconfig and see it it will still boot. Just for S&G of course.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.
On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> index 7d1451d..b9b1c52 100644
> --- a/drivers/usb/phy/Kconfig
> +++ b/drivers/usb/phy/Kconfig
> @@ -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.
greg k-h
On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
> > 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(-)
> >
> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> > index 7d1451d..b9b1c52 100644
> > --- a/drivers/usb/phy/Kconfig
> > +++ b/drivers/usb/phy/Kconfig
> > @@ -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]
This sort of proves that a driver that depends on an unknown Kconfig
symbol gets no build coverage (and will bit rot).
> 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?
Paul Bolle
Cc Yu Xu <[email protected]>
On Tue, Feb 11, 2014 at 11:01 PM, Paul Bolle <[email protected]> wrote:
> On Tue, 2014-02-11 at 13:30 -0800, Greg Kroah-Hartman wrote:
>> On Sun, Feb 09, 2014 at 07:47:39PM +0100, Richard Weinberger wrote:
>> > 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(-)
>> >
>> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> > index 7d1451d..b9b1c52 100644
>> > --- a/drivers/usb/phy/Kconfig
>> > +++ b/drivers/usb/phy/Kconfig
>> > @@ -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]
>
> This sort of proves that a driver that depends on an unknown Kconfig
> symbol gets no build coverage (and will bit rot).
>
>> 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?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
2014-02-11 3:43 GMT+04:00 Sergey Ryazanov <[email protected]>:
> 2014-02-11 2:37 GMT+04:00 Florian Fainelli <[email protected]>:
>> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:
>>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:
>>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
>>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
>>>>>> 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 <[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.
>>>>>>
>>>>>> 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.
--
BR,
Sergey
On 02/10/14 03:47, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index d876431..1c67f04 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -521,7 +521,6 @@ config MACH_ANUBIS
> select HAVE_PATA_PLATFORM
> select S3C2440_XTAL_12000000
> select S3C24XX_DCLK
> - select S3C24XX_GPIO_EXTRA64
> select S3C24XX_SIMTEC_PM if PM
> select S3C_DEV_USB_HOST
> help
OK, I will take this into samsung tree.
Thanks,
Kukjin
On 02/10/14 03:48, Richard Weinberger wrote:
> 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(-)
>
> diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
> index 1c67f04..bb1fa603 100644
> --- a/arch/arm/mach-s3c24xx/Kconfig
> +++ b/arch/arm/mach-s3c24xx/Kconfig
> @@ -561,7 +561,6 @@ config MACH_OSIRIS
> select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
> select S3C2440_XTAL_12000000
> select S3C24XX_DCLK
> - select S3C24XX_GPIO_EXTRA128
> select S3C24XX_SIMTEC_PM if PM
> select S3C_DEV_NAND
> select S3C_DEV_USB_HOST
OK good, but I will squash this with 13th for mach-s3c24xx/Kconfig when
I apply.
Thanks,
Kukjin
On Wed, Feb 12, 2014 at 02:50:30PM +0400, Sergey Ryazanov wrote:
> 2014-02-11 3:43 GMT+04:00 Sergey Ryazanov <[email protected]>:
> > 2014-02-11 2:37 GMT+04:00 Florian Fainelli <[email protected]>:
> >> 2014-02-10 4:38 GMT-08:00 Sergey Ryazanov <[email protected]>:
> >>> 2014-02-10 16:17 GMT+04:00 Oleksij Rempel <[email protected]>:
> >>>> Am 10.02.2014 13:05, schrieb Sergey Ryazanov:
> >>>>> 2014-02-10 0:03 GMT+04:00 Richard Weinberger <[email protected]>:
> >>>>>> 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 <[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.
> >>>>>>
> >>>>>> 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.
--
John W. Linville Someday the world will need a hero, and you
[email protected] might be all we have. Be ready.
On 02/11/14 12:31, Kukjin Kim wrote:
> On 02/10/14 03:48, Richard Weinberger wrote:
>> 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(-)
>>
>> diff --git a/arch/arm/mach-s3c24xx/Kconfig
>> b/arch/arm/mach-s3c24xx/Kconfig
>> index 1c67f04..bb1fa603 100644
>> --- a/arch/arm/mach-s3c24xx/Kconfig
>> +++ b/arch/arm/mach-s3c24xx/Kconfig
>> @@ -561,7 +561,6 @@ config MACH_OSIRIS
>> select S3C2410_IOTIMING if ARM_S3C2440_CPUFREQ
>> select S3C2440_XTAL_12000000
>> select S3C24XX_DCLK
>> - select S3C24XX_GPIO_EXTRA128
>> select S3C24XX_SIMTEC_PM if PM
>> select S3C_DEV_NAND
>> select S3C_DEV_USB_HOST
>
> OK good, but I will squash this with 13th for mach-s3c24xx/Kconfig when
> I apply.
>
+ Paul Bolle
Richard,
I found same patch ([PATCH] ARM: s3c24xx: get rid of unneeded selects)
for S3C24XX from Paul before your posting. So I picked that up.
Thanks,
Kukjin
On Sun, Feb 9, 2014 at 12:02 PM, Richard Weinberger <[email protected]> wrote:
> Am 09.02.2014 19:57, schrieb Alexander Shiyan:
>>> 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(-)
>>>
>>> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
>>> index b1aa6a9..8dd5fbf 100644
>>> --- a/arch/arm/mach-bcm/Kconfig
>>> +++ b/arch/arm/mach-bcm/Kconfig
>>> @@ -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
>>
Applied to armsoc/for-3.15/soc
Also added signed-off-by for Alexander Shyian and Paul Bolle.
Thanks,
csd
Richard,
On Sun, 2014-02-09 at 23:26 +0100, Richard Weinberger wrote:
> Am 09.02.2014 23:24, schrieb Paul Bolle:
> > On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> >> 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.
>
> 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?
Paul Bolle
Am 15.04.2014 09:47, schrieb Paul Bolle:
> Richard,
>
> On Sun, 2014-02-09 at 23:26 +0100, Richard Weinberger wrote:
>> Am 09.02.2014 23:24, schrieb Paul Bolle:
>>> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
>>>> 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.
>>
>> 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?
Sadly not.
Feel free to take this (and other related) patches over.
Thanks a lot for caring!
Thanks,
//richard
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]>
---
Tested only by grepping the tree!
drivers/char/hw_random/Kconfig | 12 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/picoxcell-rng.c | 181 ---------------------------------
3 files changed, 194 deletions(-)
delete mode 100644 drivers/char/hw_random/picoxcell-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 244759bbd7b7..d994c85a923c 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -251,18 +251,6 @@ config HW_RANDOM_NOMADIK
If unsure, say Y.
-config HW_RANDOM_PICOXCELL
- tristate "Picochip picoXcell true random number generator support"
- depends on HW_RANDOM && ARCH_PICOXCELL && PICOXCELL_PC3X3
- ---help---
- This driver provides kernel-side support for the Random Number
- Generator hardware found on Picochip PC3x3 and later devices.
-
- To compile this driver as a module, choose M here: the
- module will be called picoxcell-rng.
-
- If unsure, say Y.
-
config HW_RANDOM_PPC4XX
tristate "PowerPC 4xx generic true random number generator support"
depends on HW_RANDOM && PPC && 4xx
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 3ae7755a52e7..199ed283e149 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -22,7 +22,6 @@ obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o
obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o
obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o
-obj-$(CONFIG_HW_RANDOM_PICOXCELL) += picoxcell-rng.o
obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o
diff --git a/drivers/char/hw_random/picoxcell-rng.c b/drivers/char/hw_random/picoxcell-rng.c
deleted file mode 100644
index eab5448ad56f..000000000000
--- a/drivers/char/hw_random/picoxcell-rng.c
+++ /dev/null
@@ -1,181 +0,0 @@
-/*
- * Copyright (c) 2010-2011 Picochip Ltd., Jamie Iles
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * All enquiries to [email protected]
- */
-#include <linux/clk.h>
-#include <linux/delay.h>
-#include <linux/err.h>
-#include <linux/hw_random.h>
-#include <linux/io.h>
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/platform_device.h>
-
-#define DATA_REG_OFFSET 0x0200
-#define CSR_REG_OFFSET 0x0278
-#define CSR_OUT_EMPTY_MASK (1 << 24)
-#define CSR_FAULT_MASK (1 << 1)
-#define TRNG_BLOCK_RESET_MASK (1 << 0)
-#define TAI_REG_OFFSET 0x0380
-
-/*
- * The maximum amount of time in microseconds to spend waiting for data if the
- * core wants us to wait. The TRNG should generate 32 bits every 320ns so a
- * timeout of 20us seems reasonable. The TRNG does builtin tests of the data
- * for randomness so we can't always assume there is data present.
- */
-#define PICO_TRNG_TIMEOUT 20
-
-static void __iomem *rng_base;
-static struct clk *rng_clk;
-static struct device *rng_dev;
-
-static inline u32 picoxcell_trng_read_csr(void)
-{
- return __raw_readl(rng_base + CSR_REG_OFFSET);
-}
-
-static inline bool picoxcell_trng_is_empty(void)
-{
- return picoxcell_trng_read_csr() & CSR_OUT_EMPTY_MASK;
-}
-
-/*
- * Take the random number generator out of reset and make sure the interrupts
- * are masked. We shouldn't need to get large amounts of random bytes so just
- * poll the status register. The hardware generates 32 bits every 320ns so we
- * shouldn't have to wait long enough to warrant waiting for an IRQ.
- */
-static void picoxcell_trng_start(void)
-{
- __raw_writel(0, rng_base + TAI_REG_OFFSET);
- __raw_writel(0, rng_base + CSR_REG_OFFSET);
-}
-
-static void picoxcell_trng_reset(void)
-{
- __raw_writel(TRNG_BLOCK_RESET_MASK, rng_base + CSR_REG_OFFSET);
- __raw_writel(TRNG_BLOCK_RESET_MASK, rng_base + TAI_REG_OFFSET);
- picoxcell_trng_start();
-}
-
-/*
- * Get some random data from the random number generator. The hw_random core
- * layer provides us with locking.
- */
-static int picoxcell_trng_read(struct hwrng *rng, void *buf, size_t max,
- bool wait)
-{
- int i;
-
- /* Wait for some data to become available. */
- for (i = 0; i < PICO_TRNG_TIMEOUT && picoxcell_trng_is_empty(); ++i) {
- if (!wait)
- return 0;
-
- udelay(1);
- }
-
- if (picoxcell_trng_read_csr() & CSR_FAULT_MASK) {
- dev_err(rng_dev, "fault detected, resetting TRNG\n");
- picoxcell_trng_reset();
- return -EIO;
- }
-
- if (i == PICO_TRNG_TIMEOUT)
- return 0;
-
- *(u32 *)buf = __raw_readl(rng_base + DATA_REG_OFFSET);
- return sizeof(u32);
-}
-
-static struct hwrng picoxcell_trng = {
- .name = "picoxcell",
- .read = picoxcell_trng_read,
-};
-
-static int picoxcell_trng_probe(struct platform_device *pdev)
-{
- int ret;
- struct resource *mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-
- rng_base = devm_ioremap_resource(&pdev->dev, mem);
- if (IS_ERR(rng_base))
- return PTR_ERR(rng_base);
-
- rng_clk = devm_clk_get(&pdev->dev, NULL);
- if (IS_ERR(rng_clk)) {
- dev_warn(&pdev->dev, "no clk\n");
- return PTR_ERR(rng_clk);
- }
-
- ret = clk_enable(rng_clk);
- if (ret) {
- dev_warn(&pdev->dev, "unable to enable clk\n");
- return ret;
- }
-
- picoxcell_trng_start();
- ret = hwrng_register(&picoxcell_trng);
- if (ret)
- goto err_register;
-
- rng_dev = &pdev->dev;
- dev_info(&pdev->dev, "pixoxcell random number generator active\n");
-
- return 0;
-
-err_register:
- clk_disable(rng_clk);
- return ret;
-}
-
-static int picoxcell_trng_remove(struct platform_device *pdev)
-{
- hwrng_unregister(&picoxcell_trng);
- clk_disable(rng_clk);
-
- return 0;
-}
-
-#ifdef CONFIG_PM
-static int picoxcell_trng_suspend(struct device *dev)
-{
- clk_disable(rng_clk);
-
- return 0;
-}
-
-static int picoxcell_trng_resume(struct device *dev)
-{
- return clk_enable(rng_clk);
-}
-
-static const struct dev_pm_ops picoxcell_trng_pm_ops = {
- .suspend = picoxcell_trng_suspend,
- .resume = picoxcell_trng_resume,
-};
-#endif /* CONFIG_PM */
-
-static struct platform_driver picoxcell_trng_driver = {
- .probe = picoxcell_trng_probe,
- .remove = picoxcell_trng_remove,
- .driver = {
- .name = "picoxcell-trng",
- .owner = THIS_MODULE,
-#ifdef CONFIG_PM
- .pm = &picoxcell_trng_pm_ops,
-#endif /* CONFIG_PM */
- },
-};
-
-module_platform_driver(picoxcell_trng_driver);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Jamie Iles");
-MODULE_DESCRIPTION("Picochip picoXcell TRNG driver");
--
1.9.0
On Sun, 2014-02-09 at 21:18 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> > The symbol is an orphan, get rid of it.
> >
> > Signed-off-by: Richard Weinberger <[email protected]>
>
> Acked-by: Paul Bolle <[email protected]>
>
> > ---
> > crypto/asymmetric_keys/Kconfig | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> > index 03a6eb9..0320c7d 100644
> > --- a/crypto/asymmetric_keys/Kconfig
> > +++ b/crypto/asymmetric_keys/Kconfig
> > @@ -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 ).
Did anyone else ever find some time to look at this oneliner?
Paul Bolle
On Mon, 2014-02-10 at 14:58 +0000, David Howells wrote:
> Richard Weinberger <[email protected]> wrote:
>
> > 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?
Paul Bolle
On Mon, 2014-02-10 at 10:24 +0800, Lennox Wu wrote:
> 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
> 2014-02-10 2:47 GMT+08:00 Richard Weinberger <[email protected]>:
> > 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(-)
> >
> > diff --git a/arch/score/Kconfig b/arch/score/Kconfig
> > index c75d06a..c7a7b65 100644
> > --- a/arch/score/Kconfig
> > +++ b/arch/score/Kconfig
> > @@ -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
On Tue, Apr 15, 2014 at 11:06:34AM +0200, Paul Bolle wrote:
> On Sun, 2014-02-09 at 21:18 +0100, Paul Bolle wrote:
> > On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> > > The symbol is an orphan, get rid of it.
> > >
> > > Signed-off-by: Richard Weinberger <[email protected]>
> >
> > Acked-by: Paul Bolle <[email protected]>
> >
> > > ---
> > > crypto/asymmetric_keys/Kconfig | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> > > index 03a6eb9..0320c7d 100644
> > > --- a/crypto/asymmetric_keys/Kconfig
> > > +++ b/crypto/asymmetric_keys/Kconfig
> > > @@ -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 ).
>
> 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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Mon, 2014-02-10 at 10:02 +0530, Sachin Kamat wrote:
> +cc linux-samsung-soc list
>
> On 10 February 2014 01:38, Paul Bolle <[email protected]> wrote:
> > 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
It's not clear to me whether an actual decision was eventually made.
Olof, does it make sense to rebase the patch (that Sachin linked to) on
onto v3.15-rc1 and resubmit?
Paul Bolle
On Sun, 2014-02-09 at 22:36 +0100, Paul Bolle wrote:
> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> > The symbol is an orphan, get rid of it.
> >
> > Signed-off-by: Richard Weinberger <[email protected]>
>
> Paul Mundt had something similar queued a year ago:
> https://lkml.org/lkml/2013/3/11/211 . What happened?
By now the SuperH port has been orphaned. So what's the current
procedure for small SuperH fixes like this one?
Paul Bolle
> > arch/sh/drivers/dma/Kconfig | 5 ++---
> > arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
> > arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
> > 3 files changed, 3 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/sh/drivers/dma/Kconfig b/arch/sh/drivers/dma/Kconfig
> > index cfd5b90..e07afe8 100644
> > --- a/arch/sh/drivers/dma/Kconfig
> > +++ b/arch/sh/drivers/dma/Kconfig
> > @@ -12,9 +12,8 @@ config SH_DMA_IRQ_MULTI
> > default y if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7751 || \
> > CPU_SUBTYPE_SH7750S || CPU_SUBTYPE_SH7750R || \
> > CPU_SUBTYPE_SH7751R || CPU_SUBTYPE_SH7091 || \
> > - CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7764 || \
> > - CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || \
> > - CPU_SUBTYPE_SH7760
> > + CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7780 || \
> > + CPU_SUBTYPE_SH7785 CPU_SUBTYPE_SH7760
> >
> > config SH_DMA_API
> > depends on SH_DMA
> > diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> > index 02788b6..9cd81e5 100644
> > --- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
> > +++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> > @@ -32,7 +32,6 @@
> > #define CHCR_TS_HIGH_SHIFT (20 - 2) /* 2 bits for shifted low TS */
> > #elif defined(CONFIG_CPU_SUBTYPE_SH7757) || \
> > defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> > - defined(CONFIG_CPU_SUBTYPE_SH7764) || \
> > defined(CONFIG_CPU_SUBTYPE_SH7780) || \
> > defined(CONFIG_CPU_SUBTYPE_SH7785)
> > #define CHCR_TS_LOW_MASK 0x00000018
> > diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
> > index 89afb65..8ceccce 100644
> > --- a/arch/sh/include/cpu-sh4a/cpu/dma.h
> > +++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
> > @@ -14,8 +14,7 @@
> > #define DMTE4_IRQ evt2irq(0xb80)
> > #define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
> > #define SH_DMAC_BASE0 0xFE008020
> > -#elif defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> > - defined(CONFIG_CPU_SUBTYPE_SH7764)
> > +#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
> > #define DMTE0_IRQ evt2irq(0x640)
> > #define DMTE4_IRQ evt2irq(0x780)
> > #define DMAE0_IRQ evt2irq(0x6c0)
>
Hi Paul,
On Tue, Apr 15, 2014 at 11:39 AM, Paul Bolle <[email protected]> wrote:
> On Sun, 2014-02-09 at 22:36 +0100, Paul Bolle wrote:
>> On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
>> > The symbol is an orphan, get rid of it.
>> >
>> > Signed-off-by: Richard Weinberger <[email protected]>
>>
>> Paul Mundt had something similar queued a year ago:
>> https://lkml.org/lkml/2013/3/11/211 . What happened?
>
> By now the SuperH port has been orphaned. So what's the current
> procedure for small SuperH fixes like this one?
Please submit them to Andrew Morton <[email protected]>.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Paul,
On Tue, Apr 15, 2014 at 10:55:18AM +0200, Paul Bolle wrote:
> 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]>
I wish I had the bandwidth to get this properly supported, but this
seems sensible to me.
Acked-by: Jamie Iles <[email protected]>
Thanks,
Jamie
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
2014-04-15 21:08 GMT+04:00 Paul Bolle <[email protected]>:
> 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 :(
--
BR,
Sergey
On Tue, Apr 15, 2014 at 11:06:14AM +0100, Jamie Iles wrote:
> Hi Paul,
>
> On Tue, Apr 15, 2014 at 10:55:18AM +0200, Paul Bolle wrote:
> > 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]>
>
> I wish I had the bandwidth to get this properly supported, but this
> seems sensible to me.
>
> Acked-by: Jamie Iles <[email protected]>
Patch applied.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Hi Pual,
OK, we will merge it into our tree.
Best,
Lennox
2014-04-15 17:19 GMT+08:00 Paul Bolle <[email protected]>:
> On Mon, 2014-02-10 at 10:24 +0800, Lennox Wu wrote:
>> 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
>
>> 2014-02-10 2:47 GMT+08:00 Richard Weinberger <[email protected]>:
>> > 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(-)
>> >
>> > diff --git a/arch/score/Kconfig b/arch/score/Kconfig
>> > index c75d06a..c7a7b65 100644
>> > --- a/arch/score/Kconfig
>> > +++ b/arch/score/Kconfig
>> > @@ -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
>
On Thu, 2014-04-17 at 01:29 +0800, Lennox Wu wrote:
> OK, we will merge it into our tree.
Thanks!
Paul Bolle
On Tue, 2014-04-15 at 11:21 +0200, Borislav Petkov wrote:
> On Tue, Apr 15, 2014 at 11:06:34AM +0200, Paul Bolle wrote:
> > On Sun, 2014-02-09 at 21:18 +0100, Paul Bolle wrote:
> > > On Sun, 2014-02-09 at 19:47 +0100, Richard Weinberger wrote:
> > > > The symbol is an orphan, get rid of it.
> > > >
> > > > Signed-off-by: Richard Weinberger <[email protected]>
> > >
> > > Acked-by: Paul Bolle <[email protected]>
> > >
> > > > ---
> > > > crypto/asymmetric_keys/Kconfig | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
> > > > index 03a6eb9..0320c7d 100644
> > > > --- a/crypto/asymmetric_keys/Kconfig
> > > > +++ b/crypto/asymmetric_keys/Kconfig
> > > > @@ -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 ).
> >
> > 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)?
Paul Bolle
David, Koichi,
On Mon, 2014-02-10 at 09:52 +0100, Richard Weinberger wrote:
> Am 10.02.2014 09:49, schrieb Geert Uytterhoeven:
> > On Sun, Feb 9, 2014 at 9:21 PM, Richard Weinberger <[email protected]> wrote:
> >> I assumed that every kernel developer is aware of that fact that unreachable/dead code
> >> should be removed.
> >
> > Yes, it should be removed.
> >
> > But that's not what you did. You did the Kconfig-equivalent of removing a
> > "#if 0" in a C source file, which causes havoc.
>
> Fair point. I'll remove that code in v2.
> Hopefully I can catch all breakage on my testbed as many archs/configs are involved.
After first reporting this issue, in 2011, I tried to remove all dead
code hiding behind config GDBSTUB. I still have the results of that
attempt stashed away:
$ git stash show stash@{12}
arch/mn10300/Kconfig.debug | 122 +-----
arch/mn10300/boot/compressed/misc.c | 9 -
arch/mn10300/include/asm/exceptions.h | 7 -
arch/mn10300/include/asm/gdb-stub.h | 182 ---------
arch/mn10300/kernel/Makefile | 3 -
arch/mn10300/kernel/entry.S | 21 --
arch/mn10300/kernel/gdb-io-serial-low.S | 91 -----
arch/mn10300/kernel/gdb-io-serial.c | 174 ---------
arch/mn10300/kernel/gdb-io-ttysm-low.S | 93 -----
arch/mn10300/kernel/gdb-io-ttysm.c | 303 ---------------
arch/mn10300/kernel/gdb-low.S | 115 ------
arch/mn10300/kernel/gdb-stub.c | 1923 ---------------------------------------------------------------------------------------------
arch/mn10300/kernel/head.S | 10 -
arch/mn10300/kernel/mn10300-serial.c | 9 -
arch/mn10300/kernel/mn10300-serial.h | 14 -
arch/mn10300/kernel/mn10300-watchdog.c | 14 +-
arch/mn10300/kernel/process.c | 1 -
arch/mn10300/kernel/smp-low.S | 4 -
arch/mn10300/kernel/smp.c | 7 -
arch/mn10300/mm/fault.c | 9 -
arch/mn10300/mm/misalignment.c | 1 -
arch/mn10300/mm/tlb-mn10300.S | 13 -
arch/mn10300/unit-asb2303/include/unit/serial.h | 83 ----
arch/mn10300/unit-asb2305/include/unit/serial.h | 76 ----
arch/mn10300/unit-asb2305/unit-init.c | 2 -
arch/mn10300/unit-asb2364/include/unit/serial.h | 64 ----
26 files changed, 2 insertions(+), 3348 deletions(-)
By then I admitted defeat.
I might be willing to revisit this and draft a series of patches to
clean that up properly. But I think I never got any reaction on
Richard's patch or my report. And I do prefer to know beforehand what
your plans are for config GDBSTUB.
Paul Bolle
Lennox,
On Wed, 2014-04-16 at 20:30 +0200, Paul Bolle wrote:
> On Thu, 2014-04-17 at 01:29 +0800, Lennox Wu wrote:
> > 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
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
[[email protected]: re-added dropped ||]
Signed-off-by: Paul Bolle <[email protected]>
---
Submitted by Richard a few months ago as "[PATCH 21/28] Remove
CPU_SUBTYPE_SH7764".
Untested.
arch/sh/drivers/dma/Kconfig | 5 ++---
arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/sh/drivers/dma/Kconfig b/arch/sh/drivers/dma/Kconfig
index cfd5b90a8628..78bc97b1d027 100644
--- a/arch/sh/drivers/dma/Kconfig
+++ b/arch/sh/drivers/dma/Kconfig
@@ -12,9 +12,8 @@ config SH_DMA_IRQ_MULTI
default y if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7751 || \
CPU_SUBTYPE_SH7750S || CPU_SUBTYPE_SH7750R || \
CPU_SUBTYPE_SH7751R || CPU_SUBTYPE_SH7091 || \
- CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7764 || \
- CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || \
- CPU_SUBTYPE_SH7760
+ CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7780 || \
+ CPU_SUBTYPE_SH7785 || CPU_SUBTYPE_SH7760
config SH_DMA_API
depends on SH_DMA
diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
index 02788b6a03b7..9cd81e54056a 100644
--- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
+++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
@@ -32,7 +32,6 @@
#define CHCR_TS_HIGH_SHIFT (20 - 2) /* 2 bits for shifted low TS */
#elif defined(CONFIG_CPU_SUBTYPE_SH7757) || \
defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764) || \
defined(CONFIG_CPU_SUBTYPE_SH7780) || \
defined(CONFIG_CPU_SUBTYPE_SH7785)
#define CHCR_TS_LOW_MASK 0x00000018
diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
index 89afb650ce25..8ceccceae844 100644
--- a/arch/sh/include/cpu-sh4a/cpu/dma.h
+++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
@@ -14,8 +14,7 @@
#define DMTE4_IRQ evt2irq(0xb80)
#define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
#define SH_DMAC_BASE0 0xFE008020
-#elif defined(CONFIG_CPU_SUBTYPE_SH7763) || \
- defined(CONFIG_CPU_SUBTYPE_SH7764)
+#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
#define DMTE0_IRQ evt2irq(0x640)
#define DMTE4_IRQ evt2irq(0x780)
#define DMAE0_IRQ evt2irq(0x6c0)
--
1.9.3
David, Koichi,
On Tue, 2014-04-15 at 11:13 +0200, Paul Bolle wrote:
> On Mon, 2014-02-10 at 14:58 +0000, David Howells wrote:
> > Richard Weinberger <[email protected]> wrote:
> >
> > > 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?
This one is still not part of v3.16-rc1 nor part of linux-next. Is it
actually queued somewhere?
Paul Bolle
On Wed, Jun 18, 2014 at 10:09:54AM +0200, Paul Bolle wrote:
> 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.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
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 <[email protected]>:
> > 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
On Wed, 18 Jun 2014, Borislav Petkov wrote:
> > 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.
It's not in my queue of patches to be processed though, so I guess I
wasn't CCed on the initial submission. Paul, if you want me to pick it up,
please bounce it to [email protected] as well. Thanks,
--
Jiri Kosina
SUSE Labs
Hi Paul,
2014-06-18 14:25 GMT+04:00 Paul Bolle <[email protected]>:
> 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 <[email protected]>:
>> > 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?
--
BR,
Sergey
Hi Sergey,
On Wed, 2014-06-18 at 15:10 +0400, Sergey Ryazanov wrote:
> 2014-06-18 14:25 GMT+04:00 Paul Bolle <[email protected]>:
> > 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
> 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 ?
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
From: Richard Weinberger <[email protected]>
The symbol is an orphan, get rid of it.
Signed-off-by: Richard Weinberger <[email protected]>
Signed-off-by: Paul Bolle <[email protected]>
---
Bounced to trivial. Tested with make menuconfig and make oldconfig.
Since I'm sending this to Jiri myself I've upgraded my Acked-by to
Signed-off-by.
crypto/asymmetric_keys/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 03a6eb95ab50..0320c7d4b3e1 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -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).
--
1.9.3
On Wed, 2014-06-18 at 11:32 +0200, Paul Bolle wrote:
> The symbol is an orphan, get rid of it.
>
> Signed-off-by: Richard Weinberger <[email protected]>
> [[email protected]: re-added dropped ||]
> Signed-off-by: Paul Bolle <[email protected]>
> ---
> Submitted by Richard a few months ago as "[PATCH 21/28] Remove
> CPU_SUBTYPE_SH7764".
So I should have sent this with a
From: Richard Weinberger <[email protected]>
first line. Let's hope Andrew notices it.
Paul Bolle
> Untested.
>
> arch/sh/drivers/dma/Kconfig | 5 ++---
> arch/sh/include/cpu-sh4/cpu/dma-register.h | 1 -
> arch/sh/include/cpu-sh4a/cpu/dma.h | 3 +--
> 3 files changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/arch/sh/drivers/dma/Kconfig b/arch/sh/drivers/dma/Kconfig
> index cfd5b90a8628..78bc97b1d027 100644
> --- a/arch/sh/drivers/dma/Kconfig
> +++ b/arch/sh/drivers/dma/Kconfig
> @@ -12,9 +12,8 @@ config SH_DMA_IRQ_MULTI
> default y if CPU_SUBTYPE_SH7750 || CPU_SUBTYPE_SH7751 || \
> CPU_SUBTYPE_SH7750S || CPU_SUBTYPE_SH7750R || \
> CPU_SUBTYPE_SH7751R || CPU_SUBTYPE_SH7091 || \
> - CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7764 || \
> - CPU_SUBTYPE_SH7780 || CPU_SUBTYPE_SH7785 || \
> - CPU_SUBTYPE_SH7760
> + CPU_SUBTYPE_SH7763 || CPU_SUBTYPE_SH7780 || \
> + CPU_SUBTYPE_SH7785 || CPU_SUBTYPE_SH7760
>
> config SH_DMA_API
> depends on SH_DMA
> diff --git a/arch/sh/include/cpu-sh4/cpu/dma-register.h b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> index 02788b6a03b7..9cd81e54056a 100644
> --- a/arch/sh/include/cpu-sh4/cpu/dma-register.h
> +++ b/arch/sh/include/cpu-sh4/cpu/dma-register.h
> @@ -32,7 +32,6 @@
> #define CHCR_TS_HIGH_SHIFT (20 - 2) /* 2 bits for shifted low TS */
> #elif defined(CONFIG_CPU_SUBTYPE_SH7757) || \
> defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> - defined(CONFIG_CPU_SUBTYPE_SH7764) || \
> defined(CONFIG_CPU_SUBTYPE_SH7780) || \
> defined(CONFIG_CPU_SUBTYPE_SH7785)
> #define CHCR_TS_LOW_MASK 0x00000018
> diff --git a/arch/sh/include/cpu-sh4a/cpu/dma.h b/arch/sh/include/cpu-sh4a/cpu/dma.h
> index 89afb650ce25..8ceccceae844 100644
> --- a/arch/sh/include/cpu-sh4a/cpu/dma.h
> +++ b/arch/sh/include/cpu-sh4a/cpu/dma.h
> @@ -14,8 +14,7 @@
> #define DMTE4_IRQ evt2irq(0xb80)
> #define DMAE0_IRQ evt2irq(0xbc0) /* DMA Error IRQ*/
> #define SH_DMAC_BASE0 0xFE008020
> -#elif defined(CONFIG_CPU_SUBTYPE_SH7763) || \
> - defined(CONFIG_CPU_SUBTYPE_SH7764)
> +#elif defined(CONFIG_CPU_SUBTYPE_SH7763)
> #define DMTE0_IRQ evt2irq(0x640)
> #define DMTE4_IRQ evt2irq(0x780)
> #define DMAE0_IRQ evt2irq(0x6c0)
NO, there is no issue. We just want to push patches in a batched way.
The patch will show recently. Thank you.
Best,
Lennox
2014-06-18 17:10 GMT+08:00 Paul Bolle <[email protected]>:
> Lennox,
>
> On Wed, 2014-04-16 at 20:30 +0200, Paul Bolle wrote:
>> On Thu, 2014-04-17 at 01:29 +0800, Lennox Wu wrote:
>> > 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
>