[PATCH] mm/vmstat.c: Fix vmstat_update() preemption BUG.

[Steven J. Hill]

Attempting to hotplug CPUs with CONFIG_VM_EVENT_COUNTERS enabled
can cause vmstat_update() to report a BUG due to preemption not
being disabled around smp_processor_id(). Discovered on Ubiquiti
EdgeRouter Pro with Cavium Octeon II processor.

BUG: using smp_processor_id() in preemptible [] code:
kworker/1:1/269
caller is vmstat_update+0x50/0xa0
CPU: 0 PID: 269 Comm: kworker/1:1 Not tainted
4.16.0-rc4-Cavium-Octeon-9-gf83bbd5-dirty #1
Workqueue: mm_percpu_wq vmstat_update
Stack : 00260026 10009ce0  0001
  0005 800118000800
00bf  00bf 766d737461745f75
83ad 0007  0800
 818d 0001 81818a70
  8115bbb0 818a
0005 8144dc50  
80008898 800088983b30 0088 813d3054
 83ace622 00be 
00be 81121fb4  
...
Call Trace:
[] show_stack+0x94/0x128
[] dump_stack+0xa4/0xe0
[] check_preemption_disabled+0x118/0x120
[] vmstat_update+0x50/0xa0
[] process_one_work+0x144/0x348
[] worker_thread+0x150/0x4b8
[] kthread+0x110/0x140
[] ret_from_kernel_thread+0x14/0x1c

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
 mm/vmstat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 40b2db6..33581be 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1839,9 +1839,11 @@ static void vmstat_update(struct work_struct *w)
 * to occur in the future. Keep on running the
 * update worker thread.
 */
+   preempt_disable();
queue_delayed_work_on(smp_processor_id(), mm_percpu_wq,
this_cpu_ptr(_work),
round_jiffies_relative(sysctl_stat_interval));
+   preempt_enable();
}
 }
 
-- 
2.1.4

[PATCH] mm/vmstat.c: Fix vmstat_update() preemption BUG.

[Steven J. Hill]

Attempting to hotplug CPUs with CONFIG_VM_EVENT_COUNTERS enabled
can cause vmstat_update() to report a BUG due to preemption not
being disabled around smp_processor_id(). Discovered on Ubiquiti
EdgeRouter Pro with Cavium Octeon II processor.

BUG: using smp_processor_id() in preemptible [] code:
kworker/1:1/269
caller is vmstat_update+0x50/0xa0
CPU: 0 PID: 269 Comm: kworker/1:1 Not tainted
4.16.0-rc4-Cavium-Octeon-9-gf83bbd5-dirty #1
Workqueue: mm_percpu_wq vmstat_update
Stack : 00260026 10009ce0  0001
  0005 800118000800
00bf  00bf 766d737461745f75
83ad 0007  0800
 818d 0001 81818a70
  8115bbb0 818a
0005 8144dc50  
80008898 800088983b30 0088 813d3054
 83ace622 00be 
00be 81121fb4  
...
Call Trace:
[] show_stack+0x94/0x128
[] dump_stack+0xa4/0xe0
[] check_preemption_disabled+0x118/0x120
[] vmstat_update+0x50/0xa0
[] process_one_work+0x144/0x348
[] worker_thread+0x150/0x4b8
[] kthread+0x110/0x140
[] ret_from_kernel_thread+0x14/0x1c

Signed-off-by: Steven J. Hill 
---
 mm/vmstat.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 40b2db6..33581be 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1839,9 +1839,11 @@ static void vmstat_update(struct work_struct *w)
 * to occur in the future. Keep on running the
 * update worker thread.
 */
+   preempt_disable();
queue_delayed_work_on(smp_processor_id(), mm_percpu_wq,
this_cpu_ptr(_work),
round_jiffies_relative(sysctl_stat_interval));
+   preempt_enable();
}
 }
 
-- 
2.1.4

Re: [PATCH 0/2] MIPS: generic dma-coherence.h inclusion

[Steven J. Hill]

On 01/23/2018 07:40 PM, Florian Fainelli wrote:

[...]

> 
> Florian Fainelli (2):
>   MIPS: Allow including mach-generic/dma-coherence.h
>   MIPS: Update dma-coherence.h files
> 
I have tested these on our Octeon III platforms with PCIe and saw
no issues. Thanks.

Steve


Tested-by: Steven J. Hill <steven.h...@cavium.com>

Re: [PATCH RFC 0/6] MIPS: Broadcom eXtended KSEG0/1 support

[Steven J. Hill]

On 01/23/2018 07:47 PM, Florian Fainelli wrote:

[...]

> 
> Florian Fainelli (6):
>   MIPS: Allow board to override TLB initialization
>   MIPS: Allow platforms to override mapping/unmapping coherent
>   MIPS: BMIPS: Avoid referencing CKSEG1
>   MIPS: Prepare for supporting eXtended KSEG0/1
>   MIPS: BMIPS: Handshake with CFE
>   MIPS: BMIPS: Add support for eXtended KSEG0/1 (XKS01)
> 
I have tested these with your previous "MIPS: generic dma-coherence
inclusion" patchset on our Octeon III platforms with PCIe and saw
no issues. Thanks.

Steve


Tested-by: Steven J. Hill <steven.h...@cavium.com>

Re: [PATCH 0/2] MIPS: generic dma-coherence.h inclusion

[Steven J. Hill]

On 01/23/2018 07:40 PM, Florian Fainelli wrote:

[...]

> 
> Florian Fainelli (2):
>   MIPS: Allow including mach-generic/dma-coherence.h
>   MIPS: Update dma-coherence.h files
> 
I have tested these on our Octeon III platforms with PCIe and saw
no issues. Thanks.

Steve


Tested-by: Steven J. Hill 

Re: [PATCH RFC 0/6] MIPS: Broadcom eXtended KSEG0/1 support

[Steven J. Hill]

On 01/23/2018 07:47 PM, Florian Fainelli wrote:

[...]

> 
> Florian Fainelli (6):
>   MIPS: Allow board to override TLB initialization
>   MIPS: Allow platforms to override mapping/unmapping coherent
>   MIPS: BMIPS: Avoid referencing CKSEG1
>   MIPS: Prepare for supporting eXtended KSEG0/1
>   MIPS: BMIPS: Handshake with CFE
>   MIPS: BMIPS: Add support for eXtended KSEG0/1 (XKS01)
> 
I have tested these with your previous "MIPS: generic dma-coherence
inclusion" patchset on our Octeon III platforms with PCIe and saw
no issues. Thanks.

Steve


Tested-by: Steven J. Hill 

Re: [PATCH] mmc: Convert to using %pOF instead of full_name

[Steven J. Hill]

On 07/18/2017 05:00 PM, David Daney wrote:
> On 07/18/2017 02:43 PM, Rob Herring wrote:
>> Now that we have a custom printf format specifier, convert users of
>> full_name to use %pOF instead. This is preparation to remove storing
>> of the full path string for each node.
>>
>> Signed-off-by: Rob Herring <r...@kernel.org>
>> Cc: Ulf Hansson <ulf.hans...@linaro.org>
>> Cc: Ludovic Desroches <ludovic.desroc...@microchip.com>
>> Cc: Jan Glauber <jglau...@cavium.com>
>> Cc: David Daney <david.da...@cavium.com>
>> Cc: "Steven J. Hill" <steven.h...@cavium.com>
>> Cc: linux-...@vger.kernel.org
> 
> For the Cavium bits, I haven't tested them, but they look fine, so ...
> 
> Acked-by: David Daney <david.da...@cavium.com>
> 
Tested and work on our platforms

Tested-by: Steven J. Hill <steven.h...@cavium.com>

Re: [PATCH] mmc: Convert to using %pOF instead of full_name

[Steven J. Hill]

On 07/18/2017 05:00 PM, David Daney wrote:
> On 07/18/2017 02:43 PM, Rob Herring wrote:
>> Now that we have a custom printf format specifier, convert users of
>> full_name to use %pOF instead. This is preparation to remove storing
>> of the full path string for each node.
>>
>> Signed-off-by: Rob Herring 
>> Cc: Ulf Hansson 
>> Cc: Ludovic Desroches 
>> Cc: Jan Glauber 
>> Cc: David Daney 
>> Cc: "Steven J. Hill" 
>> Cc: linux-...@vger.kernel.org
> 
> For the Cavium bits, I haven't tested them, but they look fine, so ...
> 
> Acked-by: David Daney 
> 
Tested and work on our platforms

Tested-by: Steven J. Hill 

Re: [PATCH 0/4] MMC support for Octeon platforms.

[Steven J. Hill]

On 04/24/2017 02:56 PM, Ulf Hansson wrote:

[]
> 
> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer,
> unless I get an ack for it.
> 
Thanks Uffe.

Ralf, please take patch 4/4 into your -next branch. Cheers.


-Steve

Re: [PATCH 0/4] MMC support for Octeon platforms.

[Steven J. Hill]

On 04/24/2017 02:56 PM, Ulf Hansson wrote:

[]
> 
> Thanks, applied patch 1->3. Patch 4 is for the MIPS SoC maintainer,
> unless I get an ack for it.
> 
Thanks Uffe.

Ralf, please take patch 4/4 into your -next branch. Cheers.


-Steve

[PATCH 3/4] mmc: cavium: Add MMC support for Octeon SOCs.

[Steven J. Hill]

From: "Steven J. Hill" <steven.h...@cavium.com>

Add platform driver for Octeon SOCs.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Signed-off-by: David Daney <david.da...@cavium.com>
---
 drivers/mmc/host/Kconfig |  10 ++
 drivers/mmc/host/Makefile|   2 +
 drivers/mmc/host/cavium-octeon.c | 351 +++
 3 files changed, 363 insertions(+)
 create mode 100644 drivers/mmc/host/cavium-octeon.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index c882795..8b9b454 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -622,6 +622,16 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND
help
  If you say yes here SD-Cards may work on the EZkit.
 
+config MMC_CAVIUM_OCTEON
+   tristate "Cavium OCTEON SD/MMC Card Interface support"
+   depends on CAVIUM_OCTEON_SOC
+   help
+ This selects Cavium OCTEON SD/MMC card Interface.
+ If you have an OCTEON board with a Multimedia Card slot,
+ say Y or M here.
+
+ If unsure, say N.
+
 config MMC_CAVIUM_THUNDERX
tristate "Cavium ThunderX SD/MMC Card Interface support"
depends on PCI && 64BIT && (ARM64 || COMPILE_TEST)
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index f40c6b3..7f1ee0b 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -42,6 +42,8 @@ obj-$(CONFIG_MMC_SDHI)+= sh_mobile_sdhi.o
 obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
 obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o
 obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o
+octeon-mmc-objs := cavium.o cavium-octeon.o
+obj-$(CONFIG_MMC_CAVIUM_OCTEON) += octeon-mmc.o
 thunderx-mmc-objs := cavium.o cavium-thunderx.o
 obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
 obj-$(CONFIG_MMC_DW)   += dw_mmc.o
diff --git a/drivers/mmc/host/cavium-octeon.c b/drivers/mmc/host/cavium-octeon.c
new file mode 100644
index 000..772d090
--- /dev/null
+++ b/drivers/mmc/host/cavium-octeon.c
@@ -0,0 +1,351 @@
+/*
+ * Driver for MMC and SSD cards for Cavium OCTEON SOCs.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2012-2017 Cavium Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cavium.h"
+
+#define CVMX_MIO_BOOT_CTL CVMX_ADD_IO_SEG(0x000118D0ull)
+
+/*
+ * The l2c* functions below are used for the EMMC-17978 workaround.
+ *
+ * Due to a bug in the design of the MMC bus hardware, the 2nd to last
+ * cache block of a DMA read must be locked into the L2 Cache.
+ * Otherwise, data corruption may occur.
+ */
+static inline void *phys_to_ptr(u64 address)
+{
+   return (void *)(address | (1ull << 63)); /* XKPHYS */
+}
+
+/*
+ * Lock a single line into L2. The line is zeroed before locking
+ * to make sure no dram accesses are made.
+ */
+static void l2c_lock_line(u64 addr)
+{
+   char *addr_ptr = phys_to_ptr(addr);
+
+   asm volatile (
+   "cache 31, %[line]" /* Unlock the line */
+   ::[line] "m" (*addr_ptr));
+}
+
+/* Unlock a single line in the L2 cache. */
+static void l2c_unlock_line(u64 addr)
+{
+   char *addr_ptr = phys_to_ptr(addr);
+
+   asm volatile (
+   "cache 23, %[line]" /* Unlock the line */
+   ::[line] "m" (*addr_ptr));
+}
+
+/* Locks a memory region in the L2 cache. */
+static void l2c_lock_mem_region(u64 start, u64 len)
+{
+   u64 end;
+
+   /* Round start/end to cache line boundaries */
+   end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
+   start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
+
+   while (start <= end) {
+   l2c_lock_line(start);
+   start += CVMX_CACHE_LINE_SIZE;
+   }
+   asm volatile("sync");
+}
+
+/* Unlock a memory region in the L2 cache. */
+static void l2c_unlock_mem_region(u64 start, u64 len)
+{
+   u64 end;
+
+   /* Round start/end to cache line boundaries */
+   end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
+   start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
+
+   while (start <= end) {
+   l2c_unlock_line(start);
+   start += CVMX_CACHE_LINE_SIZE;
+   }
+}
+
+static void octeon_mmc_acquire_bus(struct cvm_mmc_host *host)
+{
+   if (!host->has_ciu3) {
+   down(_bootbus_sem);
+   /* For CN70XX, switch the MMC controller onto the bus. */
+   if (OCTEON_IS_MODEL(OCTEON_CN70XX))
+   writeq(0, (void __iomem *)CVMX_MIO_BOOT_CTL);
+   } else {
+   down(>mmc_serializer);
+   }
+}
+
+static void octeon_mmc_release_bus(struct cvm_mmc_host *host)
+{

[PATCH 3/4] mmc: cavium: Add MMC support for Octeon SOCs.

[Steven J. Hill]

From: "Steven J. Hill" 

Add platform driver for Octeon SOCs.

Signed-off-by: Steven J. Hill 
Signed-off-by: David Daney 
---
 drivers/mmc/host/Kconfig |  10 ++
 drivers/mmc/host/Makefile|   2 +
 drivers/mmc/host/cavium-octeon.c | 351 +++
 3 files changed, 363 insertions(+)
 create mode 100644 drivers/mmc/host/cavium-octeon.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index c882795..8b9b454 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -622,6 +622,16 @@ config SDH_BFIN_MISSING_CMD_PULLUP_WORKAROUND
help
  If you say yes here SD-Cards may work on the EZkit.
 
+config MMC_CAVIUM_OCTEON
+   tristate "Cavium OCTEON SD/MMC Card Interface support"
+   depends on CAVIUM_OCTEON_SOC
+   help
+ This selects Cavium OCTEON SD/MMC card Interface.
+ If you have an OCTEON board with a Multimedia Card slot,
+ say Y or M here.
+
+ If unsure, say N.
+
 config MMC_CAVIUM_THUNDERX
tristate "Cavium ThunderX SD/MMC Card Interface support"
depends on PCI && 64BIT && (ARM64 || COMPILE_TEST)
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index f40c6b3..7f1ee0b 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -42,6 +42,8 @@ obj-$(CONFIG_MMC_SDHI)+= sh_mobile_sdhi.o
 obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
 obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o
 obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o
+octeon-mmc-objs := cavium.o cavium-octeon.o
+obj-$(CONFIG_MMC_CAVIUM_OCTEON) += octeon-mmc.o
 thunderx-mmc-objs := cavium.o cavium-thunderx.o
 obj-$(CONFIG_MMC_CAVIUM_THUNDERX) += thunderx-mmc.o
 obj-$(CONFIG_MMC_DW)   += dw_mmc.o
diff --git a/drivers/mmc/host/cavium-octeon.c b/drivers/mmc/host/cavium-octeon.c
new file mode 100644
index 000..772d090
--- /dev/null
+++ b/drivers/mmc/host/cavium-octeon.c
@@ -0,0 +1,351 @@
+/*
+ * Driver for MMC and SSD cards for Cavium OCTEON SOCs.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2012-2017 Cavium Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "cavium.h"
+
+#define CVMX_MIO_BOOT_CTL CVMX_ADD_IO_SEG(0x000118D0ull)
+
+/*
+ * The l2c* functions below are used for the EMMC-17978 workaround.
+ *
+ * Due to a bug in the design of the MMC bus hardware, the 2nd to last
+ * cache block of a DMA read must be locked into the L2 Cache.
+ * Otherwise, data corruption may occur.
+ */
+static inline void *phys_to_ptr(u64 address)
+{
+   return (void *)(address | (1ull << 63)); /* XKPHYS */
+}
+
+/*
+ * Lock a single line into L2. The line is zeroed before locking
+ * to make sure no dram accesses are made.
+ */
+static void l2c_lock_line(u64 addr)
+{
+   char *addr_ptr = phys_to_ptr(addr);
+
+   asm volatile (
+   "cache 31, %[line]" /* Unlock the line */
+   ::[line] "m" (*addr_ptr));
+}
+
+/* Unlock a single line in the L2 cache. */
+static void l2c_unlock_line(u64 addr)
+{
+   char *addr_ptr = phys_to_ptr(addr);
+
+   asm volatile (
+   "cache 23, %[line]" /* Unlock the line */
+   ::[line] "m" (*addr_ptr));
+}
+
+/* Locks a memory region in the L2 cache. */
+static void l2c_lock_mem_region(u64 start, u64 len)
+{
+   u64 end;
+
+   /* Round start/end to cache line boundaries */
+   end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
+   start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
+
+   while (start <= end) {
+   l2c_lock_line(start);
+   start += CVMX_CACHE_LINE_SIZE;
+   }
+   asm volatile("sync");
+}
+
+/* Unlock a memory region in the L2 cache. */
+static void l2c_unlock_mem_region(u64 start, u64 len)
+{
+   u64 end;
+
+   /* Round start/end to cache line boundaries */
+   end = ALIGN(start + len - 1, CVMX_CACHE_LINE_SIZE);
+   start = ALIGN(start, CVMX_CACHE_LINE_SIZE);
+
+   while (start <= end) {
+   l2c_unlock_line(start);
+   start += CVMX_CACHE_LINE_SIZE;
+   }
+}
+
+static void octeon_mmc_acquire_bus(struct cvm_mmc_host *host)
+{
+   if (!host->has_ciu3) {
+   down(_bootbus_sem);
+   /* For CN70XX, switch the MMC controller onto the bus. */
+   if (OCTEON_IS_MODEL(OCTEON_CN70XX))
+   writeq(0, (void __iomem *)CVMX_MIO_BOOT_CTL);
+   } else {
+   down(>mmc_serializer);
+   }
+}
+
+static void octeon_mmc_release_bus(struct cvm_mmc_host *host)
+{
+   if (!host->has_ciu3)
+   up(_bootbus_sem);
+   else
+

[PATCH 4/4] MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC

[Steven J. Hill]

From: "Steven J. Hill" <steven.h...@cavium.com>

Enable the Octeon MMC driver in the defconfig.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
 arch/mips/configs/cavium_octeon_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/configs/cavium_octeon_defconfig 
b/arch/mips/configs/cavium_octeon_defconfig
index 31e3c4d..d4fda41 100644
--- a/arch/mips/configs/cavium_octeon_defconfig
+++ b/arch/mips/configs/cavium_octeon_defconfig
@@ -127,6 +127,11 @@ CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_EHCI_HCD_PLATFORM=m
 CONFIG_USB_OHCI_HCD=m
 CONFIG_USB_OHCI_HCD_PLATFORM=m
+CONFIG_MMC=y
+# CONFIG_PWRSEQ_EMMC is not set
+# CONFIG_PWRSEQ_SIMPLE is not set
+# CONFIG_MMC_BLOCK_BOUNCE is not set
+CONFIG_MMC_CAVIUM_OCTEON=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_STAGING=y
-- 
2.1.4

[PATCH 4/4] MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC

[Steven J. Hill]

From: "Steven J. Hill" 

Enable the Octeon MMC driver in the defconfig.

Signed-off-by: Steven J. Hill 
---
 arch/mips/configs/cavium_octeon_defconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/configs/cavium_octeon_defconfig 
b/arch/mips/configs/cavium_octeon_defconfig
index 31e3c4d..d4fda41 100644
--- a/arch/mips/configs/cavium_octeon_defconfig
+++ b/arch/mips/configs/cavium_octeon_defconfig
@@ -127,6 +127,11 @@ CONFIG_USB_EHCI_HCD=m
 CONFIG_USB_EHCI_HCD_PLATFORM=m
 CONFIG_USB_OHCI_HCD=m
 CONFIG_USB_OHCI_HCD_PLATFORM=m
+CONFIG_MMC=y
+# CONFIG_PWRSEQ_EMMC is not set
+# CONFIG_PWRSEQ_SIMPLE is not set
+# CONFIG_MMC_BLOCK_BOUNCE is not set
+CONFIG_MMC_CAVIUM_OCTEON=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_DS1307=y
 CONFIG_STAGING=y
-- 
2.1.4

[PATCH 1/4] mmc: core: Export API to allow hosts to get the card address

[Steven J. Hill]

From: Ulf Hansson <ulf.hans...@linaro.org>

Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.

Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org>
Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Acked-by: David Daney <david.da...@cavium.com>
---
 drivers/mmc/core/core.c  | 6 ++
 include/linux/mmc/card.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 926e0fd..f9fae34 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2555,6 +2555,12 @@ unsigned int mmc_calc_max_discard(struct mmc_card *card)
 }
 EXPORT_SYMBOL(mmc_calc_max_discard);
 
+bool mmc_card_is_blockaddr(struct mmc_card *card)
+{
+   return card ? mmc_card_blockaddr(card) : false;
+}
+EXPORT_SYMBOL(mmc_card_is_blockaddr);
+
 int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen)
 {
struct mmc_command cmd = {};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 77e61e0..4cd9450 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -307,6 +307,8 @@ static inline bool mmc_large_sector(struct mmc_card *card)
return card->ext_csd.data_sector_size == 4096;
 }
 
+bool mmc_card_is_blockaddr(struct mmc_card *card);
+
 #define mmc_card_mmc(c)((c)->type == MMC_TYPE_MMC)
 #define mmc_card_sd(c) ((c)->type == MMC_TYPE_SD)
 #define mmc_card_sdio(c)   ((c)->type == MMC_TYPE_SDIO)
-- 
2.1.4

[PATCH 1/4] mmc: core: Export API to allow hosts to get the card address

[Steven J. Hill]

From: Ulf Hansson 

Some hosts controllers, like Cavium, needs to know whether the card
operates in byte- or block-address mode. Therefore export a new API,
mmc_card_is_blockaddr(), which provides this information.

Signed-off-by: Ulf Hansson 
Signed-off-by: Steven J. Hill 
Acked-by: David Daney 
---
 drivers/mmc/core/core.c  | 6 ++
 include/linux/mmc/card.h | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 926e0fd..f9fae34 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2555,6 +2555,12 @@ unsigned int mmc_calc_max_discard(struct mmc_card *card)
 }
 EXPORT_SYMBOL(mmc_calc_max_discard);
 
+bool mmc_card_is_blockaddr(struct mmc_card *card)
+{
+   return card ? mmc_card_blockaddr(card) : false;
+}
+EXPORT_SYMBOL(mmc_card_is_blockaddr);
+
 int mmc_set_blocklen(struct mmc_card *card, unsigned int blocklen)
 {
struct mmc_command cmd = {};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 77e61e0..4cd9450 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -307,6 +307,8 @@ static inline bool mmc_large_sector(struct mmc_card *card)
return card->ext_csd.data_sector_size == 4096;
 }
 
+bool mmc_card_is_blockaddr(struct mmc_card *card);
+
 #define mmc_card_mmc(c)((c)->type == MMC_TYPE_MMC)
 #define mmc_card_sd(c) ((c)->type == MMC_TYPE_SD)
 #define mmc_card_sdio(c)   ((c)->type == MMC_TYPE_SDIO)
-- 
2.1.4

[PATCH 0/4] MMC support for Octeon platforms.

[Steven J. Hill]

From: "Steven J. Hill" <steven.h...@cavium.com>

Enable MMC support on Octeon SoCs. Tested on EdgeRouter Pro,
SFF7000, and SFF7800 platforms. This should be applied on top
of the "Cavium MMC driver" patch series from Jan Glauber.

Steven J. Hill (3):
  mmc: cavium: Fix detection of block or byte addressing.
  mmc: cavium: Add MMC support for Octeon SOCs.
  MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC

Ulf Hansson (1):
  mmc: core: Export API to allow hosts to get the card address

 arch/mips/configs/cavium_octeon_defconfig |   5 +
 drivers/mmc/core/core.c   |   6 +
 drivers/mmc/host/Kconfig  |  10 +
 drivers/mmc/host/Makefile |   2 +
 drivers/mmc/host/cavium-octeon.c  | 351 ++
 drivers/mmc/host/cavium.c |   2 +-
 include/linux/mmc/card.h  |   2 +
 7 files changed, 377 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mmc/host/cavium-octeon.c

-- 
2.1.4

[PATCH 0/4] MMC support for Octeon platforms.

[Steven J. Hill]

From: "Steven J. Hill" 

Enable MMC support on Octeon SoCs. Tested on EdgeRouter Pro,
SFF7000, and SFF7800 platforms. This should be applied on top
of the "Cavium MMC driver" patch series from Jan Glauber.

Steven J. Hill (3):
  mmc: cavium: Fix detection of block or byte addressing.
  mmc: cavium: Add MMC support for Octeon SOCs.
  MIPS: Octeon: cavium_octeon_defconfig: Enable Octeon MMC

Ulf Hansson (1):
  mmc: core: Export API to allow hosts to get the card address

 arch/mips/configs/cavium_octeon_defconfig |   5 +
 drivers/mmc/core/core.c   |   6 +
 drivers/mmc/host/Kconfig  |  10 +
 drivers/mmc/host/Makefile |   2 +
 drivers/mmc/host/cavium-octeon.c  | 351 ++
 drivers/mmc/host/cavium.c |   2 +-
 include/linux/mmc/card.h  |   2 +
 7 files changed, 377 insertions(+), 1 deletion(-)
 create mode 100644 drivers/mmc/host/cavium-octeon.c

-- 
2.1.4

[PATCH 2/4] mmc: cavium: Fix detection of block or byte addressing.

[Steven J. Hill]

From: "Steven J. Hill" <steven.h...@cavium.com>

Use the mmc_card_is_blockaddr() function to properly detect if the
card uses byte or block addressing.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
Acked-by: David Daney <david.da...@cavium.com>
---
 drivers/mmc/host/cavium.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
index d842b69..36b25e4 100644
--- a/drivers/mmc/host/cavium.c
+++ b/drivers/mmc/host/cavium.c
@@ -629,7 +629,7 @@ static u64 prepare_ext_dma(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
emm_dma = FIELD_PREP(MIO_EMM_DMA_VAL, 1) |
  FIELD_PREP(MIO_EMM_DMA_SECTOR,
-(mrq->data->blksz == 512) ? 1 : 0) |
+mmc_card_is_blockaddr(mmc->card) ? 1 : 0) |
  FIELD_PREP(MIO_EMM_DMA_RW,
 (mrq->data->flags & MMC_DATA_WRITE) ? 1 : 0) |
  FIELD_PREP(MIO_EMM_DMA_BLOCK_CNT, mrq->data->blocks) |
-- 
2.1.4

[PATCH 2/4] mmc: cavium: Fix detection of block or byte addressing.

[Steven J. Hill]

From: "Steven J. Hill" 

Use the mmc_card_is_blockaddr() function to properly detect if the
card uses byte or block addressing.

Signed-off-by: Steven J. Hill 
Acked-by: David Daney 
---
 drivers/mmc/host/cavium.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/cavium.c b/drivers/mmc/host/cavium.c
index d842b69..36b25e4 100644
--- a/drivers/mmc/host/cavium.c
+++ b/drivers/mmc/host/cavium.c
@@ -629,7 +629,7 @@ static u64 prepare_ext_dma(struct mmc_host *mmc, struct 
mmc_request *mrq)
 
emm_dma = FIELD_PREP(MIO_EMM_DMA_VAL, 1) |
  FIELD_PREP(MIO_EMM_DMA_SECTOR,
-(mrq->data->blksz == 512) ? 1 : 0) |
+mmc_card_is_blockaddr(mmc->card) ? 1 : 0) |
  FIELD_PREP(MIO_EMM_DMA_RW,
 (mrq->data->flags & MMC_DATA_WRITE) ? 1 : 0) |
  FIELD_PREP(MIO_EMM_DMA_BLOCK_CNT, mrq->data->blocks) |
-- 
2.1.4

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 04:24 PM, Steven J. Hill wrote:
> On 04/20/2017 12:12 PM, David Daney wrote:
>>
>> Steven and Jan:  Can we get around this requirement by:
>>
>> - Always set MIO_EMM_DMA[MULTI] = 1;  This way by SECTOR mode may be 
>> unimportant.
>>
>> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
>>
> No, this does not work. The 1.88GB card plugged into my 78xx
> board gives the output below. We cannot just blindly set the
> MULTI bit for all cards. These results are identical for all
> four combinations of SECTOR and MULTI values hardcoded.
> 
...for 3 of the 4 combinations. Obviously the correct one works.

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 04:24 PM, Steven J. Hill wrote:
> On 04/20/2017 12:12 PM, David Daney wrote:
>>
>> Steven and Jan:  Can we get around this requirement by:
>>
>> - Always set MIO_EMM_DMA[MULTI] = 1;  This way by SECTOR mode may be 
>> unimportant.
>>
>> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
>>
> No, this does not work. The 1.88GB card plugged into my 78xx
> board gives the output below. We cannot just blindly set the
> MULTI bit for all cards. These results are identical for all
> four combinations of SECTOR and MULTI values hardcoded.
> 
...for 3 of the 4 combinations. Obviously the correct one works.

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 12:12 PM, David Daney wrote:
> 
> Steven and Jan:  Can we get around this requirement by:
> 
> - Always set MIO_EMM_DMA[MULTI] = 1;  This way by SECTOR mode may be 
> unimportant.
> 
> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
> 
No, this does not work. The 1.88GB card plugged into my 78xx
board gives the output below. We cannot just blindly set the
MULTI bit for all cards. These results are identical for all
four combinations of SECTOR and MULTI values hardcoded.


mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SD card at address d15e
mmcblk0: mmc0:d15e SD02G 1.88 GiB
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
blk_update_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on dev mmcblk0, logical block 0, async page read
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x40090

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 12:12 PM, David Daney wrote:
> 
> Steven and Jan:  Can we get around this requirement by:
> 
> - Always set MIO_EMM_DMA[MULTI] = 1;  This way by SECTOR mode may be 
> unimportant.
> 
> - Always set MIO_EMM_DMA[SECTOR] = SUITABLE_CONSTANT.
> 
No, this does not work. The 1.88GB card plugged into my 78xx
board gives the output below. We cannot just blindly set the
MULTI bit for all cards. These results are identical for all
four combinations of SECTOR and MULTI values hardcoded.


mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SD card at address d15e
mmcblk0: mmc0:d15e SD02G 1.88 GiB
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
blk_update_request: I/O error, dev mmcblk0, sector 0
Buffer I/O error on dev mmcblk0, logical block 0, async page read
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x400900
mmcblk0: command error, retrying timeout
mmcblk0: timed out sending r/w cmd command, card status 0x40090

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 09:18 AM, Ulf Hansson wrote:
>>
>> The Cavium hardware requires knowledge of the card addressing mode.
>> We need to either restore mmc_card_blockaddr(), or create another
>> way to generate the same information. You previously suggested use
>> of the 'blksz' value, however, it has the same value regardless of
>> the card capacity. What would you suggest? Cheers.
> 
> Right. Can you explain what the Cavium hardware need it for?
>
Uffe,

In Cavium's MMC controller, the DMA engine requires software to
specify the addressing mode of the card. For DMA write operations,
the CARD_ADDR field in the MIO_EMM_DMA register is programmed with
a byte address if the media card <= 2GB. If the card is > 2GB, the
address is interpreted as a 512 byte sector address. The SECTOR bit
tells the controller how to interpret the address in CARD_ADDR. If
set to 1, use 512 byte sector addressing, otherwise it is set to 0
and byte addressing is used.

Steve

Re: MMC block addressing mode.

[Steven J. Hill]

On 04/20/2017 09:18 AM, Ulf Hansson wrote:
>>
>> The Cavium hardware requires knowledge of the card addressing mode.
>> We need to either restore mmc_card_blockaddr(), or create another
>> way to generate the same information. You previously suggested use
>> of the 'blksz' value, however, it has the same value regardless of
>> the card capacity. What would you suggest? Cheers.
> 
> Right. Can you explain what the Cavium hardware need it for?
>
Uffe,

In Cavium's MMC controller, the DMA engine requires software to
specify the addressing mode of the card. For DMA write operations,
the CARD_ADDR field in the MIO_EMM_DMA register is programmed with
a byte address if the media card <= 2GB. If the card is > 2GB, the
address is interpreted as a 512 byte sector address. The SECTOR bit
tells the controller how to interpret the address in CARD_ADDR. If
set to 1, use 512 byte sector addressing, otherwise it is set to 0
and byte addressing is used.

Steve

MMC block addressing mode.

[Steven J. Hill]

Uffe,

The Cavium hardware requires knowledge of the card addressing mode.
We need to either restore mmc_card_blockaddr(), or create another
way to generate the same information. You previously suggested use
of the 'blksz' value, however, it has the same value regardless of
the card capacity. What would you suggest? Cheers.

Steve

MMC block addressing mode.

[Steven J. Hill]

Uffe,

The Cavium hardware requires knowledge of the card addressing mode.
We need to either restore mmc_card_blockaddr(), or create another
way to generate the same information. You previously suggested use
of the 'blksz' value, however, it has the same value regardless of
the card capacity. What would you suggest? Cheers.

Steve

Re: [PATCH v13 0/6] Cavium MMC driver

[Steven J. Hill]

On 04/12/2017 05:37 PM, Aaro Koskinen wrote:
> 
> Please rather post a new version that also works with OCTEON. I don't
> think a partial driver should be merged; originally this driver was
> working fine with OCTEON so there should be no issue supporting that?!
>
Hey Aaro.

The difference is that Jan added scatter/gather support to take
advantage of the DMA FIFOs on Thunder. The same FIFOs exist on
Octeon parts 73xx, 76xx, 78xx, CNF73xx, and CNF75xx to name a
few. In order to support those, portions of the Octeon platform
code had to be rewritten as well as minor changes in the core
Cavium driver code. I have a fully tested patchset that cleanly
applies on top of Jan's v13 driver. My personal preference is
for the Octeon code to be a separate patch. I will defer that
decision to Jan, David and the MMC maintainers.

Steve

Re: [PATCH v13 0/6] Cavium MMC driver

[Steven J. Hill]

On 04/12/2017 05:37 PM, Aaro Koskinen wrote:
> 
> Please rather post a new version that also works with OCTEON. I don't
> think a partial driver should be merged; originally this driver was
> working fine with OCTEON so there should be no issue supporting that?!
>
Hey Aaro.

The difference is that Jan added scatter/gather support to take
advantage of the DMA FIFOs on Thunder. The same FIFOs exist on
Octeon parts 73xx, 76xx, 78xx, CNF73xx, and CNF75xx to name a
few. In order to support those, portions of the Octeon platform
code had to be rewritten as well as minor changes in the core
Cavium driver code. I have a fully tested patchset that cleanly
applies on top of Jan's v13 driver. My personal preference is
for the Octeon code to be a separate patch. I will defer that
decision to Jan, David and the MMC maintainers.

Steve

Re: [PATCH] MIPS: Use Makefile.postlink to insert relocations into vmlinux

[Steven J. Hill]

On 11/10/2016 04:02 AM, Matt Redfearn wrote:
> When relocatable support for MIPS was merged, there was no support for
> an architecture to add a postlink step for vmlinux. This meant that only
> invoking a target within the boot directory, such as uImage, caused the
> relocations to be inserted into vmlinux. Building just the vmlinux
> target would result in a relocatable kernel with no relocation
> information present.
> 
> Commit fbe6e37dab97 ("kbuild: add arch specific post-link Makefile")
> recified this situation, so MIPS can now define a postlink step to add
> relocation information into vmlinux, and remove the additional steps
> tacked onto boot targets.
> 
> Signed-off-by: Matt Redfearn <matt.redfe...@imgtec.com>
>
Tested on OCTEON III with relocatable kernel.

Tested-by: Steven J. Hill <steven.h...@cavium.com>

Re: [PATCH] MIPS: Use Makefile.postlink to insert relocations into vmlinux

[Steven J. Hill]

On 11/10/2016 04:02 AM, Matt Redfearn wrote:
> When relocatable support for MIPS was merged, there was no support for
> an architecture to add a postlink step for vmlinux. This meant that only
> invoking a target within the boot directory, such as uImage, caused the
> relocations to be inserted into vmlinux. Building just the vmlinux
> target would result in a relocatable kernel with no relocation
> information present.
> 
> Commit fbe6e37dab97 ("kbuild: add arch specific post-link Makefile")
> recified this situation, so MIPS can now define a postlink step to add
> relocation information into vmlinux, and remove the additional steps
> tacked onto boot targets.
> 
> Signed-off-by: Matt Redfearn 
>
Tested on OCTEON III with relocatable kernel.

Tested-by: Steven J. Hill 

[PATCH v3] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>

Changes in v3:
- Massive simplification of glue logic. Almost all the
  work is done in the SoC platform code.
Changes in v2:
- Changed comment block to acurately describe why the DMA
  properties are being set.
- Deleted 'dwc3_octeon_remove()' function as it serves
  no purpose. Also changed driver from tristate to a
  boolen as we have no plans to make it modular.
- Changed driver dependency from CAVIUM_OCTEON_SOC to
  CPU_CAVIUM_OCTEON || COMPILE_TEST per Balbi's request.

---
 drivers/usb/dwc3/Kconfig   | 10 +++
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 61 ++
 3 files changed, 72 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..f2cb24b 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.

+config USB_DWC3_OCTEON
+   bool "Cavium OCTEON III Platforms"
+   depends on CPU_CAVIUM_OCTEON || COMPILE_TEST
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..ae84a01
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,61 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill <steven.h...@cavium.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   int ret;
+
+   /*
+* Right now device-tree probed devices do not provide
+* "dma-ranges" or "dma-coherent" properties.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill <steven.h...@cavium.com");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 OCTEON Glue Layer");
-- 
1.9.1

[PATCH v3] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill 

Changes in v3:
- Massive simplification of glue logic. Almost all the
  work is done in the SoC platform code.
Changes in v2:
- Changed comment block to acurately describe why the DMA
  properties are being set.
- Deleted 'dwc3_octeon_remove()' function as it serves
  no purpose. Also changed driver from tristate to a
  boolen as we have no plans to make it modular.
- Changed driver dependency from CAVIUM_OCTEON_SOC to
  CPU_CAVIUM_OCTEON || COMPILE_TEST per Balbi's request.

---
 drivers/usb/dwc3/Kconfig   | 10 +++
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 61 ++
 3 files changed, 72 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..f2cb24b 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.

+config USB_DWC3_OCTEON
+   bool "Cavium OCTEON III Platforms"
+   depends on CPU_CAVIUM_OCTEON || COMPILE_TEST
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..ae84a01
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,61 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   int ret;
+
+   /*
+* Right now device-tree probed devices do not provide
+* "dma-ranges" or "dma-coherent" properties.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill 

[PATCH v2] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse the data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>

Changes in v2:
- Changed comment block to acurately describe why the DMA
  properties are being set.
- Deleted 'dwc3_octeon_remove()' function as it serves
  no purpose. Also changed driver from tristate to a
  boolen as we have no plans to make it modular.
- Changed driver dependency from CAVIUM_OCTEON_SOC to
  CPU_CAVIUM_OCTEON || COMPILE_TEST per Balbi's request.

---
 drivers/usb/dwc3/Kconfig   | 10 +
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 85 ++
 3 files changed, 96 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..f2cb24b 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.

+config USB_DWC3_OCTEON
+   bool "Cavium OCTEON III Platforms"
+   depends on CPU_CAVIUM_OCTEON || COMPILE_TEST
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..de46939
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,85 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill <steven.h...@cavium.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_octeon {
+   struct device   *dev;
+   void __iomem*usbctl;
+   int index;
+};
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   struct resource *res;
+   struct dwc3_octeon  *octeon;
+   int ret;
+
+   octeon = devm_kzalloc(dev, sizeof(*octeon), GFP_KERNEL);
+   if (!octeon)
+   return - ENOMEM;
+
+   /*
+* Right now device-tree probed devices do not provide
+* "dma-ranges" or "dma-coherent" properties.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, octeon);
+   octeon->dev = dev;
+
+   /* Resources for lower level OCTEON USB control. */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   octeon->usbctl = devm_ioremap_resource(dev, res);
+   if (IS_ERR(octeon->usbctl))
+   return PTR_ERR(octeon->usbctl);
+
+   /* Controller index. */
+   octeon->index = ((u64)octeon->usbctl >> 24) & 1;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill <steven.h...@cavium.com");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 OCTEON Glue Layer");
-- 
1.9.1

[PATCH v2] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse the data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill 

Changes in v2:
- Changed comment block to acurately describe why the DMA
  properties are being set.
- Deleted 'dwc3_octeon_remove()' function as it serves
  no purpose. Also changed driver from tristate to a
  boolen as we have no plans to make it modular.
- Changed driver dependency from CAVIUM_OCTEON_SOC to
  CPU_CAVIUM_OCTEON || COMPILE_TEST per Balbi's request.

---
 drivers/usb/dwc3/Kconfig   | 10 +
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 85 ++
 3 files changed, 96 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..f2cb24b 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.

+config USB_DWC3_OCTEON
+   bool "Cavium OCTEON III Platforms"
+   depends on CPU_CAVIUM_OCTEON || COMPILE_TEST
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..de46939
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,85 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_octeon {
+   struct device   *dev;
+   void __iomem*usbctl;
+   int index;
+};
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   struct resource *res;
+   struct dwc3_octeon  *octeon;
+   int ret;
+
+   octeon = devm_kzalloc(dev, sizeof(*octeon), GFP_KERNEL);
+   if (!octeon)
+   return - ENOMEM;
+
+   /*
+* Right now device-tree probed devices do not provide
+* "dma-ranges" or "dma-coherent" properties.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, octeon);
+   octeon->dev = dev;
+
+   /* Resources for lower level OCTEON USB control. */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   octeon->usbctl = devm_ioremap_resource(dev, res);
+   if (IS_ERR(octeon->usbctl))
+   return PTR_ERR(octeon->usbctl);
+
+   /* Controller index. */
+   octeon->index = ((u64)octeon->usbctl >> 24) & 1;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill 

[PATCH] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill <steven.h...@cavium.com>
---
 drivers/usb/dwc3/Kconfig   | 10 +
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 96 ++
 3 files changed, 107 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..99db6008 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_OCTEON
+   tristate "Cavium OCTEON III Platforms"
+   depends on CAVIUM_OCTEON_SOC
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..4339dd6
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,96 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill <steven.h...@cavium.com>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_octeon {
+   struct device   *dev;
+   void __iomem*usbctl;
+   int index;
+};
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   struct resource *res;
+   struct dwc3_octeon  *octeon;
+   int ret;
+
+   octeon = devm_kzalloc(dev, sizeof(*octeon), GFP_KERNEL);
+   if (!octeon)
+   return - ENOMEM;
+
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, octeon);
+   octeon->dev = dev;
+
+   /* Resources for lower level OCTEON USB control. */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   octeon->usbctl = devm_ioremap_resource(dev, res);
+   if (IS_ERR(octeon->usbctl))
+   return PTR_ERR(octeon->usbctl);
+
+   /* Controller index. */
+   octeon->index = ((u64)octeon->usbctl >> 24) & 1;
+
+   return 0;
+}
+
+static int dwc3_octeon_remove(struct platform_device *pdev)
+{
+   struct dwc3_octeon *octeon = platform_get_drvdata(pdev);
+
+   octeon->usbctl = NULL;
+   octeon->index = -1;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .remove = dwc3_octeon_remove,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill <steven.h...@cavium.com");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("DesignWare USB3 OCTEON Glue Layer");
-- 
1.9.1

[PATCH] usb: dwc3: OCTEON: add support for device tree

[Steven J. Hill]

This patch adds support to parse probe data for
the dwc3-octeon driver using device tree. The
DWC3 IP core is found on OCTEON III processors.

Signed-off-by: Steven J. Hill 
---
 drivers/usb/dwc3/Kconfig   | 10 +
 drivers/usb/dwc3/Makefile  |  1 +
 drivers/usb/dwc3/dwc3-octeon.c | 96 ++
 3 files changed, 107 insertions(+)
 create mode 100644 drivers/usb/dwc3/dwc3-octeon.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index a64ce1c..99db6008 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -105,4 +105,14 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_OCTEON
+   tristate "Cavium OCTEON III Platforms"
+   depends on CAVIUM_OCTEON_SOC
+   depends on OF
+   default USB_DWC3
+   help
+ Cavium OCTEON III SoCs with one DesignWare Core USB3 IP
+ inside (i.e. cn71xx and cn78xx).
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 22420e1..f1a7a3e 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_OCTEON)  += dwc3-octeon.o
diff --git a/drivers/usb/dwc3/dwc3-octeon.c b/drivers/usb/dwc3/dwc3-octeon.c
new file mode 100644
index 000..4339dd6
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-octeon.c
@@ -0,0 +1,96 @@
+/**
+ * dwc3-octeon.c - Cavium OCTEON III DWC3 Specific Glue Layer
+ *
+ * Copyright (C) 2016 Cavium Networks
+ *
+ * Author: Steven J. Hill 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2  of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Inspired by dwc3-exynos.c and dwc3-st.c files.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct dwc3_octeon {
+   struct device   *dev;
+   void __iomem*usbctl;
+   int index;
+};
+
+static int dwc3_octeon_probe(struct platform_device *pdev)
+{
+   struct device   *dev = >dev;
+   struct resource *res;
+   struct dwc3_octeon  *octeon;
+   int ret;
+
+   octeon = devm_kzalloc(dev, sizeof(*octeon), GFP_KERNEL);
+   if (!octeon)
+   return - ENOMEM;
+
+   /*
+* Right now device-tree probed devices don't get dma_mask set.
+* Since shared usb code relies on it, set it here for now.
+*/
+   ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
+   platform_set_drvdata(pdev, octeon);
+   octeon->dev = dev;
+
+   /* Resources for lower level OCTEON USB control. */
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   octeon->usbctl = devm_ioremap_resource(dev, res);
+   if (IS_ERR(octeon->usbctl))
+   return PTR_ERR(octeon->usbctl);
+
+   /* Controller index. */
+   octeon->index = ((u64)octeon->usbctl >> 24) & 1;
+
+   return 0;
+}
+
+static int dwc3_octeon_remove(struct platform_device *pdev)
+{
+   struct dwc3_octeon *octeon = platform_get_drvdata(pdev);
+
+   octeon->usbctl = NULL;
+   octeon->index = -1;
+
+   return 0;
+}
+
+static const struct of_device_id octeon_dwc3_match[] = {
+   { .compatible = "cavium,octeon-7130-usb-uctl", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, octeon_dwc3_match);
+
+static struct platform_driver dwc3_octeon_driver = {
+   .probe  = dwc3_octeon_probe,
+   .remove = dwc3_octeon_remove,
+   .driver = {
+   .name   = "octeon-dwc3",
+   .of_match_table = octeon_dwc3_match,
+   .pm = NULL,
+   },
+};
+module_platform_driver(dwc3_octeon_driver);
+
+MODULE_ALIAS("platform:octeon-dwc3");
+MODULE_AUTHOR("Steven J. Hill 

Re: [BISECTED REGRESSION] v4.8-rc: gpio-leds broken on OCTEON

[Steven J. Hill]

On 08/23/2016 03:36 PM, Aaro Koskinen wrote:

Hi,

gpio-leds fails to probe on OCTEON with v4.8-rc3 and when using
arch/mips/boot/dts/cavium-octeon/dlink_dsr-1000n.dts. Leds still
worked with v4.7.

I bisected this to:

commit 15cc2ed6dcf91a8658e084be4e140147161819d7
Author: Jon Hunter 
Date:   Mon Jun 20 14:49:18 2016 +0100

of/irq: Mark initialised interrupt controllers as populated

I have no idea how this is related to gpio-leds, except that on OCTEON
DTBs the gpio node is also interrupt controller...


Hey Aaro.

It is actually two patches that cause the breakage. The other is:

   commit e55aeb6ba4e8cc3549bff1e75ea1d029324bce21
   of/irq: Mark interrupt controllers as populated before initialisation

I needed to revert both of these in order to get MMC working on our 71xx 
and 78xx boards. For our MMC, I got error messages from the MMC core of 
"Invalid POWER GPIO" until I applied the second patch. I will have a fix 
worthy of upstreaming today which will be posted today.


Steve

Re: [BISECTED REGRESSION] v4.8-rc: gpio-leds broken on OCTEON

[Steven J. Hill]

On 08/23/2016 03:36 PM, Aaro Koskinen wrote:

Hi,

gpio-leds fails to probe on OCTEON with v4.8-rc3 and when using
arch/mips/boot/dts/cavium-octeon/dlink_dsr-1000n.dts. Leds still
worked with v4.7.

I bisected this to:

commit 15cc2ed6dcf91a8658e084be4e140147161819d7
Author: Jon Hunter 
Date:   Mon Jun 20 14:49:18 2016 +0100

of/irq: Mark initialised interrupt controllers as populated

I have no idea how this is related to gpio-leds, except that on OCTEON
DTBs the gpio node is also interrupt controller...


Hey Aaro.

It is actually two patches that cause the breakage. The other is:

   commit e55aeb6ba4e8cc3549bff1e75ea1d029324bce21
   of/irq: Mark interrupt controllers as populated before initialisation

I needed to revert both of these in order to get MMC working on our 71xx 
and 78xx boards. For our MMC, I got error messages from the MMC core of 
"Invalid POWER GPIO" until I applied the second patch. I will have a fix 
worthy of upstreaming today which will be posted today.


Steve

Re: Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Hey Aaro.

I wanted to apologize for my earlier email that could have been much 
shorter without being snarky. In short, we have a long test cycle and 
that we are tracking LTS support kernels and will be doing regular 
updates. A few months ago 3.10 was chosen as the next LTS version. We 
decided for stability and continued bug fixes to go with it.


Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Hey Aaro.

I wanted to apologize for my earlier email that could have been much 
shorter without being snarky. In short, we have a long test cycle and 
that we are tracking LTS support kernels and will be doing regular 
updates. A few months ago 3.10 was chosen as the next LTS version. We 
decided for stability and continued bug fixes to go with it.


Steve

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

On 11/12/2013 03:02 PM, Aaro Koskinen wrote:

Hi,

On Tue, Nov 12, 2013 at 09:18:18AM -0600, Steven J. Hill wrote:

Imagination Technologies is pleased to announce the release of its
3.10 LTS (Long-Term Support) MIPS kernel. The changelog below is
based off the stable Linux 3.10.14 release done by Greg
Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The
code repository is hosted at the Linux/MIPS project GIT:

http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.


Why multiple MIPS stable trees? There's already also
http://git.linux-mips.org/?p=ralf/linux.git;a=shortlog;h=refs/heads/linux-3.10-stable?


We track 'linux-stable' because the ones on LMO have too much lag.


Also 3.10.14 sounds quite old. Are you sure you are not missing any
important fixes?

We ran this kernel on 20 different board/core combinations. They ran our 
stress test suite continuously for over a week at 100% load with no 
failures. We have high confidence in this particular release. There are 
always bugs, so your question is somewhat ridiculous. Regarding age, go 
ask the Android team why the latest KitKat release is running a 3.4.0 
kernel and not the latest and greatest.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

On 11/12/2013 03:02 PM, Aaro Koskinen wrote:

Hi,

On Tue, Nov 12, 2013 at 09:18:18AM -0600, Steven J. Hill wrote:

Imagination Technologies is pleased to announce the release of its
3.10 LTS (Long-Term Support) MIPS kernel. The changelog below is
based off the stable Linux 3.10.14 release done by Greg
Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The
code repository is hosted at the Linux/MIPS project GIT:

http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.


Why multiple MIPS stable trees? There's already also
http://git.linux-mips.org/?p=ralf/linux.git;a=shortlog;h=refs/heads/linux-3.10-stable?


We track 'linux-stable' because the ones on LMO have too much lag.


Also 3.10.14 sounds quite old. Are you sure you are not missing any
important fixes?

We ran this kernel on 20 different board/core combinations. They ran our 
stress test suite continuously for over a week at 100% load with no 
failures. We have high confidence in this particular release. There are 
always bugs, so your question is somewhat ridiculous. Regarding age, go 
ask the Android team why the latest KitKat release is running a 3.4.0 
kernel and not the latest and greatest.


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Imagination Technologies is pleased to announce the release of its 3.10 
LTS (Long-Term Support) MIPS kernel. The changelog below is based off 
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code 
repository is hosted at the Linux/MIPS project GIT:


http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.

The Imagination MIPS Kernel Team


---
Upstream:
* Move to Linux 3.10.14

Userland visible changes:
* Fix ability to perform a soft reset on SEAD-3.
* Add 64-bit FP register support on 32-bit platforms.
* Add FPU2 IEEE754-2008 SNaN support.
* Support proAptiv/interAptiv core Perf-events.

Boot setup related changes:
* Update GCMP detection on Malta.
* Disable L2 cache on SEAD-3.
* Always register R4K clock when selected.
* Set cpu_has_mmips only if SYS_SUPPORTS_MICROMIPS is defined.
* Do not write EVA bit in the config5 CP0 register.

New drivers and features:
* Add interAptiv CPU support.
* Add proAPTIV CPU support.
* Add EVA to support 3GB virtual addressing for MIPS32 cores.
* Add ERLite-3 platform support.
* Add 64-bit address support on MIPS64R2 cores.
* Add uImage build target.
* Add MIPS32R2 SYNC optimization.
* Send IPIs using the GIC.

Developer visible changes:
* Move declaration of Octeon function fixup_irqs() to header.
* Drop obsolete NR_CPUS_DEFAULT_{1,2} config options.
* Remove -fstack-protector from CFLAGS when building images.
* CMP support needs to select SMP as well.
* Add printing of ES bit when cache error occurs.
* Enable DEVTMPFS on Malta.
* Remove ttyS2 serial support on Malta.

Fixes:
* Fix IDE PIO size calculation in IDE driver.
* Fix TLBR-use hazards for R2 cores in the TLB reload handlers.
* Fix execution hazard during watchpoint register probe.
* Fix POOL16C minor opcode enumerations for microMIPS.
* Fix gic_set_affinity infinite loop for GIC controller.
* Fix improper definition of ISA exception bit for microMIPS.
* Skip walking indirection page for crashkernels for kdump.
* Fix random crashes while loading crashkernel for kexec.
* Fix SMP core calculations when using MT support.
* Fix accessing to per-cpu data when flushing the cache.
* Fix VGA_MAP_MEM macro.
* 74K/1074K erratum workarounds.
* Bugfix of stack trace dump.
* MIPS HIGHMEM fixes for cache aliasing and non-DMA I/O.
* Revert fixrange_init() limiting to the FIXMAP region.
* Bugfix of Malta PCI bridges loop.
* Fix forgotten preempt_enable() when CPU has inclusive pcaches.
* Fix GIC interrupt offsets for Malta.
* Fix bug in using flush_cache_vunmap.
* Fix encoding for UUSK AM bits on the SegCtl registers for EVA.

Cleanups and refactors:
* Refactor boot and boot/compressed rules.
* Refactor load/entry address calculations.
* Drop FRAME_POINTER codepath in mcount.S file.
* Rearrange PTE bits into fixed positions for MIPS32R2.
* Remove X bit in page tables for HEAP/BSS.
* Rework cache flush functions.
* Re-implement VPE functionality as writes to a pseudo-device.
* Fix more section mismatch warnings.
* Remove platform_set_drvdata() in SEAD-3 USB driver.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Imagination Technologies is pleased to announce the release of its 3.10 
LTS (Long-Term Support) MIPS kernel. The changelog below is based off 
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code 
repository is hosted at the Linux/MIPS project GIT:


http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.

The Imagination MIPS Kernel Team


---
Upstream:
* Move to Linux 3.10.14

Userland visible changes:
* Fix ability to perform a soft reset on SEAD-3.
* Add 64-bit FP register support on 32-bit platforms.
* Add FPU2 IEEE754-2008 SNaN support.
* Support proAptiv/interAptiv core Perf-events.

Boot setup related changes:
* Update GCMP detection on Malta.
* Disable L2 cache on SEAD-3.
* Always register R4K clock when selected.
* Set cpu_has_mmips only if SYS_SUPPORTS_MICROMIPS is defined.
* Do not write EVA bit in the config5 CP0 register.

New drivers and features:
* Add interAptiv CPU support.
* Add proAPTIV CPU support.
* Add EVA to support 3GB virtual addressing for MIPS32 cores.
* Add ERLite-3 platform support.
* Add 64-bit address support on MIPS64R2 cores.
* Add uImage build target.
* Add MIPS32R2 SYNC optimization.
* Send IPIs using the GIC.

Developer visible changes:
* Move declaration of Octeon function fixup_irqs() to header.
* Drop obsolete NR_CPUS_DEFAULT_{1,2} config options.
* Remove -fstack-protector from CFLAGS when building images.
* CMP support needs to select SMP as well.
* Add printing of ES bit when cache error occurs.
* Enable DEVTMPFS on Malta.
* Remove ttyS2 serial support on Malta.

Fixes:
* Fix IDE PIO size calculation in IDE driver.
* Fix TLBR-use hazards for R2 cores in the TLB reload handlers.
* Fix execution hazard during watchpoint register probe.
* Fix POOL16C minor opcode enumerations for microMIPS.
* Fix gic_set_affinity infinite loop for GIC controller.
* Fix improper definition of ISA exception bit for microMIPS.
* Skip walking indirection page for crashkernels for kdump.
* Fix random crashes while loading crashkernel for kexec.
* Fix SMP core calculations when using MT support.
* Fix accessing to per-cpu data when flushing the cache.
* Fix VGA_MAP_MEM macro.
* 74K/1074K erratum workarounds.
* Bugfix of stack trace dump.
* MIPS HIGHMEM fixes for cache aliasing and non-DMA I/O.
* Revert fixrange_init() limiting to the FIXMAP region.
* Bugfix of Malta PCI bridges loop.
* Fix forgotten preempt_enable() when CPU has inclusive pcaches.
* Fix GIC interrupt offsets for Malta.
* Fix bug in using flush_cache_vunmap.
* Fix encoding for UUSK AM bits on the SegCtl registers for EVA.

Cleanups and refactors:
* Refactor boot and boot/compressed rules.
* Refactor load/entry address calculations.
* Drop FRAME_POINTER codepath in mcount.S file.
* Rearrange PTE bits into fixed positions for MIPS32R2.
* Remove X bit in page tables for HEAP/BSS.
* Rework cache flush functions.
* Re-implement VPE functionality as writes to a pseudo-device.
* Fix more section mismatch warnings.
* Remove platform_set_drvdata() in SEAD-3 USB driver.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Imagination Technologies is pleased to announce the release of its 3.10 
LTS (Long-Term Support) MIPS kernel. The changelog below is based off 
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code 
repository is hosted at the Linux/MIPS project GIT:


http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.

The Imagination MIPS Kernel Team


---
Upstream:
* Move to Linux 3.10.14

Userland visible changes:
* Fix ability to perform a soft reset on SEAD-3.
* Add 64-bit FP register support on 32-bit platforms.
* Add FPU2 IEEE754-2008 SNaN support.
* Support proAptiv/interAptiv core Perf-events.

Boot setup related changes:
* Update GCMP detection on Malta.
* Disable L2 cache on SEAD-3.
* Always register R4K clock when selected.
* Set cpu_has_mmips only if SYS_SUPPORTS_MICROMIPS is defined.
* Do not write EVA bit in the config5 CP0 register.

New drivers and features:
* Add interAptiv CPU support.
* Add proAPTIV CPU support.
* Add EVA to support 3GB virtual addressing for MIPS32 cores.
* Add ERLite-3 platform support.
* Add 64-bit address support on MIPS64R2 cores.
* Add uImage build target.
* Add MIPS32R2 SYNC optimization.
* Send IPIs using the GIC.

Developer visible changes:
* Move declaration of Octeon function fixup_irqs() to header.
* Drop obsolete NR_CPUS_DEFAULT_{1,2} config options.
* Remove -fstack-protector from CFLAGS when building images.
* CMP support needs to select SMP as well.
* Add printing of ES bit when cache error occurs.
* Enable DEVTMPFS on Malta.
* Remove ttyS2 serial support on Malta.

Fixes:
* Fix IDE PIO size calculation in IDE driver.
* Fix TLBR-use hazards for R2 cores in the TLB reload handlers.
* Fix execution hazard during watchpoint register probe.
* Fix POOL16C minor opcode enumerations for microMIPS.
* Fix gic_set_affinity infinite loop for GIC controller.
* Fix improper definition of ISA exception bit for microMIPS.
* Skip walking indirection page for crashkernels for kdump.
* Fix random crashes while loading crashkernel for kexec.
* Fix SMP core calculations when using MT support.
* Fix accessing to per-cpu data when flushing the cache.
* Fix VGA_MAP_MEM macro.
* 74K/1074K erratum workarounds.
* Bugfix of stack trace dump.
* MIPS HIGHMEM fixes for cache aliasing and non-DMA I/O.
* Revert fixrange_init() limiting to the FIXMAP region.
* Bugfix of Malta PCI bridges loop.
* Fix forgotten preempt_enable() when CPU has inclusive pcaches.
* Fix GIC interrupt offsets for Malta.
* Fix bug in using flush_cache_vunmap.
* Fix encoding for UUSK AM bits on the SegCtl registers for EVA.

Cleanups and refactors:
* Refactor boot and boot/compressed rules.
* Refactor load/entry address calculations.
* Drop FRAME_POINTER codepath in mcount.S file.
* Rearrange PTE bits into fixed positions for MIPS32R2.
* Remove X bit in page tables for HEAP/BSS.
* Rework cache flush functions.
* Re-implement VPE functionality as writes to a pseudo-device.
* Fix more section mismatch warnings.
* Remove platform_set_drvdata() in SEAD-3 USB driver.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Release of Linux MTI-3.10-LTS kernel.

[Steven J. Hill]

Imagination Technologies is pleased to announce the release of its 3.10 
LTS (Long-Term Support) MIPS kernel. The changelog below is based off 
the stable Linux 3.10.14 release done by Greg Kroah-Hartman in commit
8c15abc94c737f9120d3d4a550abbcbb9be121f6 back on October 1st. The code 
repository is hosted at the Linux/MIPS project GIT:


http://git.linux-mips.org/?p=linux-mti.git;a=summary

We look forward to any comments or feedback.

The Imagination MIPS Kernel Team


---
Upstream:
* Move to Linux 3.10.14

Userland visible changes:
* Fix ability to perform a soft reset on SEAD-3.
* Add 64-bit FP register support on 32-bit platforms.
* Add FPU2 IEEE754-2008 SNaN support.
* Support proAptiv/interAptiv core Perf-events.

Boot setup related changes:
* Update GCMP detection on Malta.
* Disable L2 cache on SEAD-3.
* Always register R4K clock when selected.
* Set cpu_has_mmips only if SYS_SUPPORTS_MICROMIPS is defined.
* Do not write EVA bit in the config5 CP0 register.

New drivers and features:
* Add interAptiv CPU support.
* Add proAPTIV CPU support.
* Add EVA to support 3GB virtual addressing for MIPS32 cores.
* Add ERLite-3 platform support.
* Add 64-bit address support on MIPS64R2 cores.
* Add uImage build target.
* Add MIPS32R2 SYNC optimization.
* Send IPIs using the GIC.

Developer visible changes:
* Move declaration of Octeon function fixup_irqs() to header.
* Drop obsolete NR_CPUS_DEFAULT_{1,2} config options.
* Remove -fstack-protector from CFLAGS when building images.
* CMP support needs to select SMP as well.
* Add printing of ES bit when cache error occurs.
* Enable DEVTMPFS on Malta.
* Remove ttyS2 serial support on Malta.

Fixes:
* Fix IDE PIO size calculation in IDE driver.
* Fix TLBR-use hazards for R2 cores in the TLB reload handlers.
* Fix execution hazard during watchpoint register probe.
* Fix POOL16C minor opcode enumerations for microMIPS.
* Fix gic_set_affinity infinite loop for GIC controller.
* Fix improper definition of ISA exception bit for microMIPS.
* Skip walking indirection page for crashkernels for kdump.
* Fix random crashes while loading crashkernel for kexec.
* Fix SMP core calculations when using MT support.
* Fix accessing to per-cpu data when flushing the cache.
* Fix VGA_MAP_MEM macro.
* 74K/1074K erratum workarounds.
* Bugfix of stack trace dump.
* MIPS HIGHMEM fixes for cache aliasing and non-DMA I/O.
* Revert fixrange_init() limiting to the FIXMAP region.
* Bugfix of Malta PCI bridges loop.
* Fix forgotten preempt_enable() when CPU has inclusive pcaches.
* Fix GIC interrupt offsets for Malta.
* Fix bug in using flush_cache_vunmap.
* Fix encoding for UUSK AM bits on the SegCtl registers for EVA.

Cleanups and refactors:
* Refactor boot and boot/compressed rules.
* Refactor load/entry address calculations.
* Drop FRAME_POINTER codepath in mcount.S file.
* Rearrange PTE bits into fixed positions for MIPS32R2.
* Remove X bit in page tables for HEAP/BSS.
* Rework cache flush functions.
* Re-implement VPE functionality as writes to a pseudo-device.
* Fix more section mismatch warnings.
* Remove platform_set_drvdata() in SEAD-3 USB driver.

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V9 03/13] MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature

[Steven J. Hill]

On 06/22/2013 09:10 PM, Huacai Chen wrote:


Is the 3rd patch of V10 is OK to be accepted now? If so, could the
patchset of V10 be merged into 3.11?

The merge window for 3.11 is closed at this point. You should get it 
prepared for 3.12, so start tracking the 'mips-for-linux-next' branch 
with your patches.


Acked-by: Steven J. Hill 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V9 03/13] MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature

[Steven J. Hill]

On 06/22/2013 09:10 PM, Huacai Chen wrote:


Is the 3rd patch of V10 is OK to be accepted now? If so, could the
patchset of V10 be merged into 3.11?

The merge window for 3.11 is closed at this point. You should get it 
prepared for 3.12, so start tracking the 'mips-for-linux-next' branch 
with your patches.


Acked-by: Steven J. Hill steven.h...@imgtec.com

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V9 03/13] MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 12:24 AM, Huacai Chen wrote:
> Loongson-3 maintains cache coherency by hardware. So we introduce a cpu 
> feature named cpu_has_coherent_cache and use it to modify MIPS's cache 
> flushing functions.
> 
> Signed-off-by: Huacai Chen  Signed-off-by: Hongliang Tao
>  Signed-off-by: Hua Yan  --- 
> arch/mips/include/asm/cacheflush.h |6 + 
> arch/mips/include/asm/cpu-features.h   |3 ++ 
> .../asm/mach-loongson/cpu-feature-overrides.h  |6 + 
> arch/mips/mm/c-r4k.c   |   21
> ++- 4 files changed, 34 insertions(+), 2 deletions(-)
> 
Hello.

This patch masks the problem that you are not properly probing your L1 caches
to start with. For some reason in 'probe_pcache()' you reach the default case
where the primary data cache is marked as having aliases. If your CPU truly is
HW coherent with no aliases, then MIPS_CACHE_ALIASES should never get set.
Fixing this would eliminate the 'arch/mips/include/asm/cacheflush.h' and
'arch/mips/mm/c-r4k.c' changes completely. There is no need to add more CPU
feature bits for this single platform, thus changes to 'cpu-features.h' and
'cpu-features-overrides.h' will not be accepted.

Also, please do not copy the  mailing list
unless your patch touches files outside of 'arch/mips' in order to cut down
traffic on an already busy list. Thanks.

Steve
- -


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFm7WAACgkQgyK5H2Ic36eHuwCeKZjp1+arkoheEpeuzjJkQskN
/7MAnig14A03hWxRvfqDOMbMFKXpZBO8
=HRPU
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V9 03/13] MIPS: Loongson: Introduce and use cpu_has_coherent_cache feature

[Steven J. Hill]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 12:24 AM, Huacai Chen wrote:
 Loongson-3 maintains cache coherency by hardware. So we introduce a cpu 
 feature named cpu_has_coherent_cache and use it to modify MIPS's cache 
 flushing functions.
 
 Signed-off-by: Huacai Chen che...@lemote.com Signed-off-by: Hongliang Tao
 ta...@lemote.com Signed-off-by: Hua Yan y...@lemote.com --- 
 arch/mips/include/asm/cacheflush.h |6 + 
 arch/mips/include/asm/cpu-features.h   |3 ++ 
 .../asm/mach-loongson/cpu-feature-overrides.h  |6 + 
 arch/mips/mm/c-r4k.c   |   21
 ++- 4 files changed, 34 insertions(+), 2 deletions(-)
 
Hello.

This patch masks the problem that you are not properly probing your L1 caches
to start with. For some reason in 'probe_pcache()' you reach the default case
where the primary data cache is marked as having aliases. If your CPU truly is
HW coherent with no aliases, then MIPS_CACHE_ALIASES should never get set.
Fixing this would eliminate the 'arch/mips/include/asm/cacheflush.h' and
'arch/mips/mm/c-r4k.c' changes completely. There is no need to add more CPU
feature bits for this single platform, thus changes to 'cpu-features.h' and
'cpu-features-overrides.h' will not be accepted.

Also, please do not copy the linux-kernel@vger.kernel.org mailing list
unless your patch touches files outside of 'arch/mips' in order to cut down
traffic on an already busy list. Thanks.

Steve
- -
sjh...@mips.com
steven.h...@imgtec.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFm7WAACgkQgyK5H2Ic36eHuwCeKZjp1+arkoheEpeuzjJkQskN
/7MAnig14A03hWxRvfqDOMbMFKXpZBO8
=HRPU
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: unresoved symbol _gp_disp

[Steven J. Hill]

> I have written a loadble module ( which gets complied
> along with kernel) which does some floating point
> operation.
>  
NO FLOATING POINT in the kernel PERIOD. Either use integer
operations, or redo your software architecture and do the
floating point in userspace.

-Steve
-
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/

Re: unresoved symbol _gp_disp

[Steven J. Hill]

 I have written a loadble module ( which gets complied
 along with kernel) which does some floating point
 operation.
  
NO FLOATING POINT in the kernel PERIOD. Either use integer
operations, or redo your software architecture and do the
floating point in userspace.

-Steve
-
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/

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

Alan Cox wrote:
> 
> > The way that I architected the raw NAND flash device driver was to
> > break it into 2 parts. 'nand.c' contains the actual driver code and
> > is considered to be device independent. 'spia.c' is the device
> > dependent part. You should write your own version of 'spia.c' and
> 
> So the Config.in is wrong since I can select spia on x86
> 
Indeed. That should be fixed now with this patch. Now onto the stuff
for ESR.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 spia.diff

Re: Cross-reference analysis reveals problems in 2.4.6pre9

[Steven J. Hill]

"Eric S. Raymond" wrote:
> 
> CONFIG_MIPS_EV64120
> CONFIG_MIPS_EV96100
> CONFIG_MIPS_ITE8172
> CONFIG_MIPS_IVR
> CONFIG_MIPS_PB1000
> CONFIG_MIPS_UNCACHED
> CONFIG_NINO
> CONFIG_NINO_16MB
> CONFIG_NINO_4MB
> CONFIG_NINO_8MB
>
I can fill in the blanks on all of these for you. I won't clutter
up the mailing list with the complete descriptions.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

"Adam J. Richter" wrote:
> 
> If there is no architecture on which
> linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its
> "pristine" form, then the CONFIG_MTD_NAND_SPIA should be commented
> out from drivers/mtd/nand/Config.in to avoid wasting the time of
> users and automated build processes alike that just want to build
> all available modules by default.  (At the moment, this code is
> not even bracketed by CONFIG_EXPERIMENTAL, although changing that
> would not be a sufficient fix.)
> 
David has fixed this and it is in the MTD CVS now.

> Alternatively, if you will send me a one line description
> of each of those four #define parameters, I will be happy to do the grunt
> work of submiting a patch to you or whoever is appropriate to replace
> those values with module and setup parameters that default to those
> values if there are #defined and otherwise will abort initialization
> if they are not #defined and no values were provided at run time.
> (Or, better, yet, you can do this work!)
> 
I have filled in the #define values and placed the new 'spia.c' into
the MTD CVS. I added comments for how those various values should be
defined. Shame on me for forgetting to comment those months ago. Sorry.
I believe that fixes things now?

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

Adam J. Richter wrote:
 
 If there is no architecture on which
 linux-2.4.6-pre8/drivers/mtd/nand/spia.c will compile in its
 pristine form, then the CONFIG_MTD_NAND_SPIA should be commented
 out from drivers/mtd/nand/Config.in to avoid wasting the time of
 users and automated build processes alike that just want to build
 all available modules by default.  (At the moment, this code is
 not even bracketed by CONFIG_EXPERIMENTAL, although changing that
 would not be a sufficient fix.)
 
David has fixed this and it is in the MTD CVS now.

 Alternatively, if you will send me a one line description
 of each of those four #define parameters, I will be happy to do the grunt
 work of submiting a patch to you or whoever is appropriate to replace
 those values with module and setup parameters that default to those
 values if there are #defined and otherwise will abort initialization
 if they are not #defined and no values were provided at run time.
 (Or, better, yet, you can do this work!)
 
I have filled in the #define values and placed the new 'spia.c' into
the MTD CVS. I added comments for how those various values should be
defined. Shame on me for forgetting to comment those months ago. Sorry.
I believe that fixes things now?

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Re: Cross-reference analysis reveals problems in 2.4.6pre9

[Steven J. Hill]

Eric S. Raymond wrote:
 
 CONFIG_MIPS_EV64120
 CONFIG_MIPS_EV96100
 CONFIG_MIPS_ITE8172
 CONFIG_MIPS_IVR
 CONFIG_MIPS_PB1000
 CONFIG_MIPS_UNCACHED
 CONFIG_NINO
 CONFIG_NINO_16MB
 CONFIG_NINO_4MB
 CONFIG_NINO_8MB

I can fill in the blanks on all of these for you. I won't clutter
up the mailing list with the complete descriptions.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

Alan Cox wrote:
 
  The way that I architected the raw NAND flash device driver was to
  break it into 2 parts. 'nand.c' contains the actual driver code and
  is considered to be device independent. 'spia.c' is the device
  dependent part. You should write your own version of 'spia.c' and
 
 So the Config.in is wrong since I can select spia on x86
 
Indeed. That should be fixed now with this patch. Now onto the stuff
for ESR.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 spia.diff

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

"Adam J. Richter" wrote:
> 
> linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four
> undefined symbols, presumably intended to be #define constants,
> although I am not sure what their values are supposed to be:
> 
> IO_BASE
> FIO_BASE
> PEDR
> PEDDR
> 
The way that I architected the raw NAND flash device driver was to
break it into 2 parts. 'nand.c' contains the actual driver code and
is considered to be device independent. 'spia.c' is the device
dependent part. You should write your own version of 'spia.c' and
"simply" fill in the addresses for the IO address and control
register address depending on your specific hardware. The above
symbols are only defined for my specific hardware. They should be
changed to values used on your hardware platform. Let me know if
you need further assistance.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Re: linux-2.4.6-pre8/drivers/mtd/nand/spia.c: undefined symbols

[Steven J. Hill]

Adam J. Richter wrote:
 
 linux-2.4.6-pre8/drivers/mtd/nand/spia.c references four
 undefined symbols, presumably intended to be #define constants,
 although I am not sure what their values are supposed to be:
 
 IO_BASE
 FIO_BASE
 PEDR
 PEDDR
 
The way that I architected the raw NAND flash device driver was to
break it into 2 parts. 'nand.c' contains the actual driver code and
is considered to be device independent. 'spia.c' is the device
dependent part. You should write your own version of 'spia.c' and
simply fill in the addresses for the IO address and control
register address depending on your specific hardware. The above
symbols are only defined for my specific hardware. They should be
changed to values used on your hardware platform. Let me know if
you need further assistance.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
-
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/

Bad aic7xxx driver or bad harddisk?

[Steven J. Hill]

 kernel: (scsi0:A:6:0): SCB 19 - Abort Tag Completed. 
May  9 21:11:53 ptecdev1 kernel: Recovery SCB completes 
May  9 21:11:53 ptecdev1 kernel: Recovery code awake 
May  9 21:11:53 ptecdev1 kernel: aic7xxx_abort returns 8194 
May  9 21:12:26 ptecdev1 kernel: scsi0:0:6:0: Attempting to queue an ABORT messa
ge 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): Queuing a recovery SCB 
May  9 21:12:26 ptecdev1 kernel: scsi0:0:6:0: Device is disconnected, re-queuing
 SCB 
May  9 21:12:26 ptecdev1 kernel: Recovery code sleeping 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): Abort Tag Message Sent 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): SCB 5 - Abort Tag Completed. 
May  9 21:12:26 ptecdev1 kernel: Recovery SCB completes 
May  9 21:12:26 ptecdev1 kernel: Recovery code awake 
May  9 21:12:26 ptecdev1 kernel: aic7xxx_abort returns 8194 
May  9 21:12:27 ptecdev1 kernel: SCSI disk error : host 0 channel 0 id 6 lun 0 r
eturn code = 802 
May  9 21:12:27 ptecdev1 kernel: [valid=0] Info fld=0x0, Current sd08:11: sense 
key None 
May  9 21:12:27 ptecdev1 kernel:  I/O error: dev 08:11, sector 2034752 
May  9 21:12:57 ptecdev1 kernel: scsi0:0:6:0: Attempting to queue an ABORT messa
ge 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): Queuing a recovery SCB 
May  9 21:12:57 ptecdev1 kernel: scsi0:0:6:0: Device is disconnected, re-queuing
 SCB 
May  9 21:12:57 ptecdev1 kernel: Recovery code sleeping 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): Abort Tag Message Sent 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): SCB 5 - Abort Tag Completed. 
May  9 21:12:57 ptecdev1 kernel: Recovery SCB completes 
May  9 21:12:57 ptecdev1 kernel: Recovery code awake 
May  9 21:12:57 ptecdev1 kernel: aic7xxx_abort returns 8194 

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

Bad aic7xxx driver or bad harddisk?

[Steven J. Hill]

 kernel: (scsi0:A:6:0): SCB 19 - Abort Tag Completed. 
May  9 21:11:53 ptecdev1 kernel: Recovery SCB completes 
May  9 21:11:53 ptecdev1 kernel: Recovery code awake 
May  9 21:11:53 ptecdev1 kernel: aic7xxx_abort returns 8194 
May  9 21:12:26 ptecdev1 kernel: scsi0:0:6:0: Attempting to queue an ABORT messa
ge 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): Queuing a recovery SCB 
May  9 21:12:26 ptecdev1 kernel: scsi0:0:6:0: Device is disconnected, re-queuing
 SCB 
May  9 21:12:26 ptecdev1 kernel: Recovery code sleeping 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): Abort Tag Message Sent 
May  9 21:12:26 ptecdev1 kernel: (scsi0:A:6:0): SCB 5 - Abort Tag Completed. 
May  9 21:12:26 ptecdev1 kernel: Recovery SCB completes 
May  9 21:12:26 ptecdev1 kernel: Recovery code awake 
May  9 21:12:26 ptecdev1 kernel: aic7xxx_abort returns 8194 
May  9 21:12:27 ptecdev1 kernel: SCSI disk error : host 0 channel 0 id 6 lun 0 r
eturn code = 802 
May  9 21:12:27 ptecdev1 kernel: [valid=0] Info fld=0x0, Current sd08:11: sense 
key None 
May  9 21:12:27 ptecdev1 kernel:  I/O error: dev 08:11, sector 2034752 
May  9 21:12:57 ptecdev1 kernel: scsi0:0:6:0: Attempting to queue an ABORT messa
ge 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): Queuing a recovery SCB 
May  9 21:12:57 ptecdev1 kernel: scsi0:0:6:0: Device is disconnected, re-queuing
 SCB 
May  9 21:12:57 ptecdev1 kernel: Recovery code sleeping 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): Abort Tag Message Sent 
May  9 21:12:57 ptecdev1 kernel: (scsi0:A:6:0): SCB 5 - Abort Tag Completed. 
May  9 21:12:57 ptecdev1 kernel: Recovery SCB completes 
May  9 21:12:57 ptecdev1 kernel: Recovery code awake 
May  9 21:12:57 ptecdev1 kernel: aic7xxx_abort returns 8194 

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

Question on including 'math.h' from C runtime...

[Steven J. Hill]

Greetings.

I checked in the archives and did not see a discussion of this
anywhere. I have received some Linux kernel code from a project
that I have inherited and a couple of the drivers are including
math.h from the C library. This being the header file from
'/usr/include/math.h' in most cases. There are only two places
in the kernel that also include this header file. They are:

   drivers/atm/iphase.c
   drivers/net/hamradio/soundmodem/gentbl.c

As far as I can tell '/usr/include/math.h' is just full of
defines and the header files it includes are also a bunch
of defines with a few macro functions sprinkled in. Can someone
shed light on if this is bad or not and why it would be done
or necessary? Thanks.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

Question on including 'math.h' from C runtime...

[Steven J. Hill]

Greetings.

I checked in the archives and did not see a discussion of this
anywhere. I have received some Linux kernel code from a project
that I have inherited and a couple of the drivers are including
math.h from the C library. This being the header file from
'/usr/include/math.h' in most cases. There are only two places
in the kernel that also include this header file. They are:

   drivers/atm/iphase.c
   drivers/net/hamradio/soundmodem/gentbl.c

As far as I can tell '/usr/include/math.h' is just full of
defines and the header files it includes are also a bunch
of defines with a few macro functions sprinkled in. Can someone
shed light on if this is bad or not and why it would be done
or necessary? Thanks.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

Re: LILO error with 2.4.3-pre1...

[Steven J. Hill]

Andre Tomt wrote:
> 
> >'lba32' extensions Copyright (C) 1999,2000 John Coffman
>  ^^
> 
> Add lba32 as the top line in lilo.conf. Re-run lilo.
> 
> > Fatal: geo_comp_addr: Cylinder number is too big (1274 > 1023)
> 
> Before 2.4.3pre1, your kernel just happened to toss itself below cylinder
> 1024.
> 
> > Go ahead, call me idiot :).
> 
> Idiot. :-)
> 
And since Andre was the last person to email me and call me an idiot,
I will reply to his response :). Yup, that was the case and I added
'lba32' to my '/etc/lilo.conf' and things work great. I knew it was
something simple, but I just don't pay attention to LILO much anymore.
Thanks everyone.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

LILO error with 2.4.3-pre1...

[Steven J. Hill]

Hmm, needed 2.4.3-pre1 and went to install with LILO using
'lilo -v' and got this:

   LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
   'lba32' extensions Copyright (C) 1999,2000 John Coffman

   Reading boot sector from /dev/hda
   Merging with /boot/boot.b
   Boot image: /boot/vmlinuz-2.4.2
   Added linux *
   Boot image: /boot/vmlinuz-2.4.3-pre1
   Fatal: geo_comp_addr: Cylinder number is too big (1274 > 1023)

Neato. I don't have time to dig through LILO source code right
now, so here are my system specs:

Linux Distribution: RedHat 6.2 with all latest updates
Hard Disk: Maxtor 52049H3 (20GB) IDE
CPU: Dual PII-266MHz
RAM: 256MB PC100
Result of 'fdisk /dev/hda -l':

   Disk /dev/hda: 255 heads, 63 sectors, 2491 cylinders
   Units = cylinders of 16065 * 512 bytes

 Device BootStart   EndBlocks   Id  System
  /dev/hda1   * 1  1513  12153141   83  Linux
  /dev/hda2  1514  1530136552+  82  Linux swap
  /dev/hda3  1531  2491   7719232+  83  Linux

I have no idea why the 1023 limit is coming up considering 2.4.2 and
LILO were working just fine together and I have a newer BIOS that has
not problems detecting the driver properly. Go ahead, call me idiot :).

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

LILO error with 2.4.3-pre1...

[Steven J. Hill]

Hmm, needed 2.4.3-pre1 and went to install with LILO using
'lilo -v' and got this:

   LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger
   'lba32' extensions Copyright (C) 1999,2000 John Coffman

   Reading boot sector from /dev/hda
   Merging with /boot/boot.b
   Boot image: /boot/vmlinuz-2.4.2
   Added linux *
   Boot image: /boot/vmlinuz-2.4.3-pre1
   Fatal: geo_comp_addr: Cylinder number is too big (1274  1023)

Neato. I don't have time to dig through LILO source code right
now, so here are my system specs:

Linux Distribution: RedHat 6.2 with all latest updates
Hard Disk: Maxtor 52049H3 (20GB) IDE
CPU: Dual PII-266MHz
RAM: 256MB PC100
Result of 'fdisk /dev/hda -l':

   Disk /dev/hda: 255 heads, 63 sectors, 2491 cylinders
   Units = cylinders of 16065 * 512 bytes

 Device BootStart   EndBlocks   Id  System
  /dev/hda1   * 1  1513  12153141   83  Linux
  /dev/hda2  1514  1530136552+  82  Linux swap
  /dev/hda3  1531  2491   7719232+  83  Linux

I have no idea why the 1023 limit is coming up considering 2.4.2 and
LILO were working just fine together and I have a newer BIOS that has
not problems detecting the driver properly. Go ahead, call me idiot :).

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/

Re: LILO error with 2.4.3-pre1...

[Steven J. Hill]

Andre Tomt wrote:
 
 'lba32' extensions Copyright (C) 1999,2000 John Coffman
  ^^
 
 Add lba32 as the top line in lilo.conf. Re-run lilo.
 
  Fatal: geo_comp_addr: Cylinder number is too big (1274  1023)
 
 Before 2.4.3pre1, your kernel just happened to toss itself below cylinder
 1024.
 
  Go ahead, call me idiot :).
 
 Idiot. :-)
 
And since Andre was the last person to email me and call me an idiot,
I will reply to his response :). Yup, that was the case and I added
'lba32' to my '/etc/lilo.conf' and things work great. I knew it was
something simple, but I just don't pay attention to LILO much anymore.
Thanks everyone.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'http://www.cotw.com/pubkey.txt'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D
-
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/