* RE: SATA hang on 8315E triggered by heavy flash write?
From: Xie Shaohui-B21989 @ 2013-05-23 6:04 UTC (permalink / raw)
To: Anthony Foiani; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <g8v362qg8.fsf@dworkin.scrye.com>
Hi, Anthony Foiani,
Thanks for the confirmation.=20
So it seems the NOR write break the signal Integrity of SATA.
I don't have schematic and board right now, could you please measure signal=
s related to NOR write to see if anything abnormal? Is the board use FPGA o=
r CPLD to control signal?
If stop NOR write, could the SATA recover and work?
Best Regards,=20
Shaohui Xie
> -----Original Message-----
> From: Anthony Foiani [mailto:tkil@scrye.com]
> Sent: Thursday, May 23, 2013 1:52 PM
> To: Xie Shaohui-B21989
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org
> Subject: Re: SATA hang on 8315E triggered by heavy flash write?
>=20
>=20
> Shaohui --
>=20
> Thanks for the quick reply! Please find my investigation and results
> below.
>=20
> Xie Shaohui-B21989 <B21989@freescale.com> writes:
>=20
> > 1. only update NOR for a long enough time, for ex. tens of seconds,
> > see if error happens;
>=20
> It seems that I can do this without any errors:
>=20
> / # flash_erase /dev/mtd1 0 0
> Erasing 64 Kibyte @ 7f0000 -- 100 % complete
> / # dd if=3D/dev/zero of=3D/dev/mtd1
> dd: writing '/dev/mtd1': No space left on device
> 16385+0 records in
> 16384+0 records out
> 8388608 bytes (8.0MB) copied, 62.399439 seconds, 131.3KB/s
>=20
> > 2. only r/w SSD without NOR operation, see if error happens;
>=20
> Again, no problem:
>=20
> /ssd # ls -al biggie.bin
> -rw-r--r-- 1 root root 2330607084 May 22 19:34 biggie.bin
> /ssd # ls -alh biggie.bin
> -rw-r--r-- 1 root root 2.2G May 22 19:34 biggie.bin
> /ssd # time cp biggie.bin biggie2.bin
> real 3m 27.55s
> user 0m 2.60s
> sys 2m 16.13s
>=20
> > 3. r/w SSD first and keep it run, then start to read NOR, if no
> > error for a long time, then start to write NOR, see how long the
> > error will happen.
>=20
> Doing a NOR read during heavy SATA r/w seems to succeed, with no errors
> on the console:
>=20
> [window 1]
> /ssd # time cp biggie.bin biggie2.bin
>=20
> [window 2]
> / # dd if=3D/dev/mtd1 of=3D/dev/null
> 16384+0 records in
> 16384+0 records out
> 8388608 bytes (8.0MB) copied, 6.380613 seconds, 1.3MB/s
>=20
> Doing a NOR write fails almost instantly (within a second):
>=20
> [window 1]
> /ssd # time cp biggie.bin biggie2.bin
>=20
> [window 2]
> / # dd if=3D/dev/zero of=3D/dev/mtd1
>=20
> [console]
> [ 5160.269106] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action
> 0x6 frozen
> [ 5160.276387] ata2.00: failed command: READ DMA
> [ 5160.280905] ata2.00: cmd c8/00:00:60:f3:01/00:00:00:00:00/e0 tag 0
> dma 131072 in
> [ 5160.280928] res 50/00:00:f0:c0:48/00:00:00:00:00/e0 Emask
> 0x10 (ATA bus error)
> [ 5160.296386] ata2.00: status: { DRDY }
> [ 5160.300195] ata2: hard resetting link
> [ 5160.347858] ata2: setting speed (in hard reset)
> [ 5170.439981] ata2: No Signature Update
> [ 5170.611901] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 5170.618204] ata2.00: link online but device misclassified
> [ 5175.623918] ata2.00: qc timeout (cmd 0xec)
> [ 5175.628147] ata2.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
> [ 5175.634347] ata2.00: revalidation failed (errno=3D-5)
> [ 5175.639373] ata2: hard resetting link
> [ 5176.143847] ata2: Hardreset failed, not off-lined 0
> [ 5176.155867] ata2: setting speed (in hard reset)
> [ 5185.743871] ata2: No Signature Update
> [ 5185.915900] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> [ 5185.922203] ata2.00: link online but device misclassified
> [ 5195.927910] ata2.00: qc timeout (cmd 0xec)
> [ 5195.932140] ata2.00: failed to IDENTIFY (I/O error, err_mask=3D0x4)
> [ 5195.938342] ata2.00: revalidation failed (errno=3D-5)
> [ 5195.943430] ata2: hard resetting link
> [ 5196.443885] ata2: Hardreset failed, not off-lined 0
> ...
>=20
> At this point, a hard reset / full power cycle is needed to recover.
>=20
> The board is an MPC8315ERDB derivative, and I'm running a patched
> 3.4.36 kernel.
>=20
> I've uploaded some (possibly) relevant files to:
>=20
> http://foiani.home.dyndns.org/~tony/linux/ppc-sata-issues-201305/
>=20
> There is a diff from 3.4.36, a devtree, and a kernel config.
>=20
> Please let me know if there is any more information that I can contribute=
.
>=20
> Best regards,
> Anthony Foiani
^ permalink raw reply
* Re: SATA hang on 8315E triggered by heavy flash write?
From: Anthony Foiani @ 2013-05-23 5:52 UTC (permalink / raw)
To: Xie Shaohui-B21989; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ED492CCEAF882048BC2237DE806547C90B1DFA93@039-SN2MPN1-013.039d.mgd.msft.net>
Shaohui --
Thanks for the quick reply! Please find my investigation and results
below.
Xie Shaohui-B21989 <B21989@freescale.com> writes:
> 1. only update NOR for a long enough time, for ex. tens of seconds,
> see if error happens;
It seems that I can do this without any errors:
/ # flash_erase /dev/mtd1 0 0
Erasing 64 Kibyte @ 7f0000 -- 100 % complete
/ # dd if=/dev/zero of=/dev/mtd1
dd: writing '/dev/mtd1': No space left on device
16385+0 records in
16384+0 records out
8388608 bytes (8.0MB) copied, 62.399439 seconds, 131.3KB/s
> 2. only r/w SSD without NOR operation, see if error happens;
Again, no problem:
/ssd # ls -al biggie.bin
-rw-r--r-- 1 root root 2330607084 May 22 19:34 biggie.bin
/ssd # ls -alh biggie.bin
-rw-r--r-- 1 root root 2.2G May 22 19:34 biggie.bin
/ssd # time cp biggie.bin biggie2.bin
real 3m 27.55s
user 0m 2.60s
sys 2m 16.13s
> 3. r/w SSD first and keep it run, then start to read NOR, if no
> error for a long time, then start to write NOR, see how long the
> error will happen.
Doing a NOR read during heavy SATA r/w seems to succeed, with no
errors on the console:
[window 1]
/ssd # time cp biggie.bin biggie2.bin
[window 2]
/ # dd if=/dev/mtd1 of=/dev/null
16384+0 records in
16384+0 records out
8388608 bytes (8.0MB) copied, 6.380613 seconds, 1.3MB/s
Doing a NOR write fails almost instantly (within a second):
[window 1]
/ssd # time cp biggie.bin biggie2.bin
[window 2]
/ # dd if=/dev/zero of=/dev/mtd1
[console]
[ 5160.269106] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 5160.276387] ata2.00: failed command: READ DMA
[ 5160.280905] ata2.00: cmd c8/00:00:60:f3:01/00:00:00:00:00/e0 tag 0 dma 131072 in
[ 5160.280928] res 50/00:00:f0:c0:48/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
[ 5160.296386] ata2.00: status: { DRDY }
[ 5160.300195] ata2: hard resetting link
[ 5160.347858] ata2: setting speed (in hard reset)
[ 5170.439981] ata2: No Signature Update
[ 5170.611901] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 5170.618204] ata2.00: link online but device misclassified
[ 5175.623918] ata2.00: qc timeout (cmd 0xec)
[ 5175.628147] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 5175.634347] ata2.00: revalidation failed (errno=-5)
[ 5175.639373] ata2: hard resetting link
[ 5176.143847] ata2: Hardreset failed, not off-lined 0
[ 5176.155867] ata2: setting speed (in hard reset)
[ 5185.743871] ata2: No Signature Update
[ 5185.915900] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 5185.922203] ata2.00: link online but device misclassified
[ 5195.927910] ata2.00: qc timeout (cmd 0xec)
[ 5195.932140] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 5195.938342] ata2.00: revalidation failed (errno=-5)
[ 5195.943430] ata2: hard resetting link
[ 5196.443885] ata2: Hardreset failed, not off-lined 0
...
At this point, a hard reset / full power cycle is needed to recover.
The board is an MPC8315ERDB derivative, and I'm running a patched
3.4.36 kernel.
I've uploaded some (possibly) relevant files to:
http://foiani.home.dyndns.org/~tony/linux/ppc-sata-issues-201305/
There is a diff from 3.4.36, a devtree, and a kernel config.
Please let me know if there is any more information that I can
contribute.
Best regards,
Anthony Foiani
^ permalink raw reply
* 3.9.2/3.9.3: stack overrun on s390x and ppc64 (WAS Re: 3.9.2: xfstests triggered panic)
From: CAI Qian @ 2013-05-23 4:57 UTC (permalink / raw)
To: linux-s390, linuxppc-dev
Cc: Dave Chinner, LKML, Steve Best, xfs, stable, Hendrik Brueckner
In-Reply-To: <20130523034611.GX24543@dastard>
Original report:
http://oss.sgi.com/archives/xfs/2013-05/msg00683.html
Also seen on Power7:
http://marc.info/?l=3Dlinux-kernel&m=3D136927904900692&w=3D2
CAI Qian
----- Original Message -----
> From: "Dave Chinner" <david@fromorbit.com>
> To: "CAI Qian" <caiqian@redhat.com>
> Cc: "LKML" <linux-kernel@vger.kernel.org>, stable@vger.kernel.org, xfs@os=
s.sgi.com
> Sent: Thursday, May 23, 2013 11:46:11 AM
> Subject: Re: 3.9.2: xfstests triggered panic
>=20
> On Wed, May 22, 2013 at 11:16:56PM -0400, CAI Qian wrote:
> > ----- Original Message -----
> > > From: "Dave Chinner" <david@fromorbit.com>
> > > To: "CAI Qian" <caiqian@redhat.com>
> > > Cc: "LKML" <linux-kernel@vger.kernel.org>, stable@vger.kernel.org,
> > > xfs@oss.sgi.com
> > > Sent: Wednesday, May 22, 2013 5:53:00 PM
> > > Subject: Re: 3.9.2: xfstests triggered panic
> > >=20
> > > On Wed, May 22, 2013 at 04:39:58AM -0400, CAI Qian wrote:
> > > > Reproduced on almost all s390x guests by running xfstests.
> > > >=20
> > > > 14634.396658=C2=A8 XFS (dm-1): Mounting Filesystem
> > > > 14634.525522=C2=A8 XFS (dm-1): Ending clean mount
> > > > 14640.413007=C2=A8 <000000000017c6d4>=C2=A8 idle_balance+0x1a0/0x3=
40
> > > > 14640.413010=C2=A8 <000000000063303e>=C2=A8 __schedule+0xa22/0xaf0
> > > > 14640.428279=C2=A8 <0000000000630da6>=C2=A8 schedule_timeout+0x186=
/0x2c0
> > > > 14640.428289=C2=A8 <00000000001cf864>=C2=A8 rcu_gp_kthread+0x1bc/0=
x298
> > > > 14640.428300=C2=A8 <0000000000158c5a>=C2=A8 kthread+0xe6/0xec
> > > > 14640.428304=C2=A8 <0000000000634de6>=C2=A8 kernel_thread_starter+=
0x6/0xc
> > > > 14640.428308=C2=A8 <0000000000634de0>=C2=A8 kernel_thread_starter+=
0x0/0xc
> > > > 14640.428311=C2=A8 Last Breaking-Event-Address:
> > > > 14640.428314=C2=A8 <000000000016bd76>=C2=A8 walk_tg_tree_from+0x3a=
/0xf4
> > > > 14640.428319=C2=A8 list_add corruption. next->prev should be prev
> > > > (0000000000000918
> > > > ), but was (null). (next=3D (null)).
> > >=20
> > > Where's XFS in this? walk_tg_tree_from() is part of the scheduler
> > > code. This kind of implies a stack corruption....
> > >=20
> > > > Sometimes, this pops up,
> > > > [16907.275002] WARNING: at kernel/rcutree.c:1960
> > > >=20
> > > > or this,
> > > > 15316.154171=C2=A8 XFS (dm-1): Mounting Filesystem
> > > > 15316.255796=C2=A8 XFS (dm-1): Ending clean mount
> > > > 15320.364246=C2=A8 00000000006367a2: e310b0080004 =
lg
> > > > %r1,8(%r
> > > > 11)
> > > > 15320.364249=C2=A8 00000000006367a8: 41101010 =
la
> > > > %r1,16(%
> > > > r1)
> > > > 15320.364251=C2=A8 00000000006367ac: e33010000004 =
lg
> > > > %r3,0(%r
> > > > 1)
> > > > 15320.364252=C2=A8 Call Trace:
> > > > 15320.364252=C2=A8 Last Breaking-Event-Address:
> > > > 15320.364253=C2=A8 =EF=BF=BD <0000000000000000>=C2=A8 Kernel stack=
overflow.
> > > > 15320.364308=C2=A8 CPU: 0 Tainted: GF W 3.9.2 #1
> > > > 15320.364309=C2=A8 Process rhts-test-runne (pid: 625, task:
> > > > 000000003dccc890,
> > > > ksp: 0
> > >=20
> > > .... and there you go - a stack overflow. Your kernel stack size is
> > > too small.
> > >=20
> > > I'd suggest that you need 16k stacks on s390 - IIRC every function
> > > call has 128 byte stack frame, and there are call chains 70-80
> > > functions deep in the storage stack...
> > Hmm, I am unsure how to set to 16k stack there
>=20
> Are you build a 64 bit s390 kernel or a 32 bit kernel? 32 bit
> kernels only have an 8k stack size, 64 bit kernels are 16k (see
> arch/s390/Makefile).
>=20
> $ git grep STACK_SIZE arch/s390 |head -2
> arch/s390/Makefile:STACK_SIZE :=3D 8192
> arch/s390/Makefile:STACK_SIZE :=3D 16384
>=20
> As it is, the stack frame usage is worse than I thought:
>=20
> $ git grep STACK_FRAME_OVERHEAD arch/s390 |head -2
> arch/s390/include/uapi/asm/ptrace.h:#define STACK_FRAME_OVERHEAD 96 =
/*
> size of minimum stack frame */
> arch/s390/include/uapi/asm/ptrace.h:#define STACK_FRAME_OVERHEAD 160 =
/*
> size of minimum stack frame */
>=20
> Overhead is 96 bytes for 32 bit and 160 bytes for 64 bit. So 16k
> stack size is going to have big troubles with a 70-80 function deep
> call chain.
>=20
> As for powerpc:
>=20
> arch/powerpc/include/asm/ppc_asm.h:#define STACKFRAMESIZE 256
>=20
> Yeah, same issue.
>=20
> But, seriously, these stack traces are meaningless to anyone not
> familiar with s390 or power7 - they indicate a problem detected
> in the idle loop, not where ever the stack overran.
>=20
> Can you please work with the s390/power7 people to obtain whatever
> stack it was that overflowed, and we can go from there.
>=20
> Cheers,
>=20
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>=20
^ permalink raw reply
* Re: [PATCH] perf: Power7: Make CPI stack events available in sysfs
From: Paul Mackerras @ 2013-05-22 22:23 UTC (permalink / raw)
To: Sukadev Bhattiprolu; +Cc: linux-kernel, Arnaldo Carvalho de Melo, linuxppc-dev
In-Reply-To: <20130406164803.GA408@us.ibm.com>
On Sat, Apr 06, 2013 at 09:48:03AM -0700, Sukadev Bhattiprolu wrote:
> >From bdeacf7175241f6c79b5b2be0fa6b20b0d0b7d1c Mon Sep 17 00:00:00 2001
> From: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> Date: Sat, 6 Apr 2013 08:48:26 -0700
> Subject: [PATCH] perf: Power7: Make CPI stack events available in sysfs
>
> A set of Power7 events are often used for Cycles Per Instruction (CPI) stack
> analysis. Make these events available in sysfs (/sys/devices/cpu/events/) so
> they can be identified using their symbolic names:
>
> perf stat -e 'cpu/PM_CMPLU_STALL_DCACHE_MISS/' /bin/ls
>
> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
From: Sebastian Hesselbarth @ 2013-05-22 21:17 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, Simon Baatz, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <20130522210257.GM31290@titan.lakedaemon.net>
On 05/22/2013 11:02 PM, Jason Cooper wrote:
> On Wed, May 22, 2013 at 10:55:43PM +0200, Sebastian Hesselbarth wrote:
>> On 05/22/2013 10:36 PM, Simon Baatz wrote:
>>> Hi Sebastian,
>>>
>>> On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
>>>> With DT support for mv643xx_eth, board specific init for some boards now
>>>> is unneccessary. Remove those board files, Kconfig entries, and
>>>> corresponding entries in kirkwood_defconfig.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
>>>> ---
>>>> Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
>>>> the lock-up is not caused by accessing clock gating registers but rather
>>>> non-existent device registers. This will be addressed by dtsi separation
>>>> for kirkwood and bobcat SoC variants.
>>>>
>>>> Changelog:
>>>> v3->v4:
>>>> - remove more boards that don't require board specific setup
>>>>
>> ...
>>
>> I would stick with "marvell,kirkwood" only. This is SoC init code and
>> we do not distinguish variants here at all.
>
> Agreed, nice catch Simon.
I just confirmed all kirkwood dts/dtsi properly set "marvell,kirkwood"
in their compatible strings. Will remove all other comapatible strings
from mach-kirkwood/board-dt.c as Simon suggested for v5.
Sebastian
^ permalink raw reply
* [PATCHv2 1/1] powerpc: Force 32 bit MSIs on systems lacking firmware support
From: Brian King @ 2013-05-22 21:07 UTC (permalink / raw)
To: benh; +Cc: klebers, brking, linuxppc-dev
Recent commit e61133dda480062d221f09e4fc18f66763f8ecd0 added support
for a new firmware feature to force an adapter to use 32 bit MSIs.
However, this firmware is not available for all systems. The hack below
allows devices needing 32 bit MSIs to work on these systems as well.
It is careful to only enable this on Gen2 slots, which should limit
this to configurations where this hack is needed and tested to work.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/msi.c | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff -puN arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr arch/powerpc/platforms/pseries/msi.c
--- linux/arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr 2013-05-15 10:44:46.000000000 -0500
+++ linux-bjking1/arch/powerpc/platforms/pseries/msi.c 2013-05-22 10:51:17.000000000 -0500
@@ -401,6 +401,7 @@ static int rtas_setup_msi_irqs(struct pc
struct msi_desc *entry;
struct msi_msg msg;
int nvec = nvec_in;
+ int use_32bit_msi_hack = 0;
pdn = get_pdn(pdev);
if (!pdn)
@@ -428,15 +429,43 @@ static int rtas_setup_msi_irqs(struct pc
*/
again:
if (type == PCI_CAP_ID_MSI) {
- if (pdn->force_32bit_msi)
+ if (pdn->force_32bit_msi) {
rc = rtas_change_msi(pdn, RTAS_CHANGE_32MSI_FN, nvec);
- else
+ if (rc < 0) {
+ /*
+ * We only want to run the 32 bit MSI hack below if
+ * the max bus speed is Gen2 speed
+ */
+ if (pdev->bus->max_bus_speed != PCIE_SPEED_5_0GT)
+ return rc;
+
+ use_32bit_msi_hack = 1;
+ }
+ } else
+ rc = -1;
+
+ if (rc < 0)
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec);
- if (rc < 0 && !pdn->force_32bit_msi) {
+ if (rc < 0) {
pr_debug("rtas_msi: trying the old firmware call.\n");
rc = rtas_change_msi(pdn, RTAS_CHANGE_FN, nvec);
}
+
+ if (use_32bit_msi_hack && rc > 0) {
+ u32 addr_hi, addr_lo;
+
+ /*
+ * We should only get in here for IODA1 configs. This is based on the
+ * fact that we using RTAS for MSIs, we don't have the 32 bit MSI RTAS
+ * support, and we are in a PCIe Gen2 slot.
+ */
+ dev_info(&pdev->dev, "rtas_msi: No 32 bit MSI firmware support, forcing 32 bit MSI\n");
+ pci_read_config_dword(pdev, pdev->msi_cap + PCI_MSI_ADDRESS_HI, &addr_hi);
+ addr_lo = 0xffff0000 | ((addr_hi >> (48 - 32)) << 4);
+ pci_write_config_dword(pdev, pdev->msi_cap + PCI_MSI_ADDRESS_LO, addr_lo);
+ pci_write_config_dword(pdev, pdev->msi_cap + PCI_MSI_ADDRESS_HI, 0);
+ }
} else
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSIX_FN, nvec);
_
^ permalink raw reply
* Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling
From: Scott Wood @ 2013-05-22 21:06 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Alexey Kardashevskiy, linux-kernel, kvm-ppc, Alexander Graf,
Paul Mackerras, linuxppc-dev, David Gibson
In-Reply-To: <1369105607-20957-4-git-send-email-aik@ozlabs.ru>
On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:
> diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> index 8465c2a..da6bf61 100644
> --- a/arch/powerpc/kvm/powerpc.c
> @@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext)
> +++ b/arch/powerpc/kvm/powerpc.c
> break;
> #endif
> case KVM_CAP_SPAPR_MULTITCE:
> + case KVM_CAP_SPAPR_TCE_IOMMU:
> r =3D 1;
> break;
> default:
Don't advertise SPAPR capabilities if it's not book3s -- and probably =20
there's some additional limitation that would be appropriate.
> @@ -1025,6 +1026,17 @@ long kvm_arch_vm_ioctl(struct file *filp,
> r =3D kvm_vm_ioctl_create_spapr_tce(kvm, &create_tce);
> goto out;
> }
> + case KVM_CREATE_SPAPR_TCE_IOMMU: {
> + struct kvm_create_spapr_tce_iommu create_tce_iommu;
> + struct kvm *kvm =3D filp->private_data;
> +
> + r =3D -EFAULT;
> + if (copy_from_user(&create_tce_iommu, argp,
> + sizeof(create_tce_iommu)))
> + goto out;
> + r =3D kvm_vm_ioctl_create_spapr_tce_iommu(kvm, =20
> &create_tce_iommu);
> + goto out;
> + }
> #endif /* CONFIG_PPC_BOOK3S_64 */
>=20
> #ifdef CONFIG_KVM_BOOK3S_64_HV
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 5a2afda..450c82a 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -667,6 +667,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_PPC_RTAS 91
> #define KVM_CAP_IRQ_XICS 92
> #define KVM_CAP_SPAPR_MULTITCE (0x110000 + 89)
> +#define KVM_CAP_SPAPR_TCE_IOMMU (0x110000 + 90)
Hmm...
> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {
> #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct =20
> kvm_device_attr)
> #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct =20
> kvm_device_attr)
>=20
> +/* ioctl for SPAPR TCE IOMMU */
> +#define KVM_CREATE_SPAPR_TCE_IOMMU _IOW(KVMIO, 0xe4, struct =20
> kvm_create_spapr_tce_iommu)
Shouldn't this go under the vm ioctl section?
-Scott=
^ permalink raw reply
* Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
From: Jason Cooper @ 2013-05-22 21:02 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Simon Baatz, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <519D30CF.9040904@gmail.com>
On Wed, May 22, 2013 at 10:55:43PM +0200, Sebastian Hesselbarth wrote:
> On 05/22/2013 10:36 PM, Simon Baatz wrote:
> >Hi Sebastian,
> >
> >On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
> >>With DT support for mv643xx_eth, board specific init for some boards now
> >>is unneccessary. Remove those board files, Kconfig entries, and
> >>corresponding entries in kirkwood_defconfig.
> >>
> >>Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
> >>---
> >>Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
> >>the lock-up is not caused by accessing clock gating registers but rather
> >>non-existent device registers. This will be addressed by dtsi separation
> >>for kirkwood and bobcat SoC variants.
> >>
> >>Changelog:
> >>v3->v4:
> >>- remove more boards that don't require board specific setup
> >>
> ...
> >We still have:
> >
> >static const char * const kirkwood_dt_board_compat[] = {
> > "globalscale,dreamplug",
> > "globalscale,guruplug",
> > "dlink,dns-320",
> > "dlink,dns-325",
> > "iom,iconnect",
> > "raidsonic,ib-nas62x0",
> > "qnap,ts219",
> > "seagate,dockstar",
> > "seagate,goflexnet",
> > "buffalo,lsxl",
> > "iom,ix2-200",
> > "keymile,km_kirkwood",
> > "lacie,cloudbox",
> > "lacie,inetspace_v2",
> > "lacie,netspace_lite_v2",
> > "lacie,netspace_max_v2",
> > "lacie,netspace_mini_v2",
> > "lacie,netspace_v2",
> > "mpl,cec4",
> > "netgear,readynas-duo-v2",
> > "plathome,openblocks-a6",
> > "usi,topkick",
> > "zyxel,nsa310",
> > NULL
> >};
> >
> >in that file. I think it does not make sense that we need to list
> >boards here that can be described fully by DT. When adding such a
> >board in the future, you will still need to adapt board-dt.c.
>
> True, will remove the redundant compatible strings for v5.
> Actually, if I am not missing something, all compatible strings except
> "marvell,kirkwood" are redundant as long as board.dts append it
> correctly.
>
> >Should we remove the boards that you removed above here as well and
> >add
> >
> > "marvell,kirkwood-88f6192",
> > "marvell,kirkwood-88f6281",
> > "marvell,kirkwood-88f6282",
> > "marvell,kirkwood-88f6283",
> > "marvell,kirkwood-88f6702",
> > "marvell,kirkwood-98DX4122",
> >
> >or even just state "marvell,kirkwood"?
>
> I would stick with "marvell,kirkwood" only. This is SoC init code and
> we do not distinguish variants here at all.
Agreed, nice catch Simon.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
From: Sebastian Hesselbarth @ 2013-05-22 21:02 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, linux-kernel, Lennert Buytenhek,
netdev, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <20130522201607.GA18823@obsidianresearch.com>
On 05/22/2013 10:16 PM, Jason Gunthorpe wrote:
> On Wed, May 22, 2013 at 10:04:02PM +0200, Sebastian Hesselbarth wrote:
>> Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
>> MAC address register contents on clock gating but also some important
>> registers are reset to values that would break ethernet. This patch
>
> FWIW, we found that the bootloader has to write to PSC1, the driver
> doesn't work with the power on/reset value of the register. So I think
> it is safe to assume that all kirkwood bootloaders alter the value.
It is safe to assume the bootloader alters it, but that modification is
lost when clocks get gated. I assume on clock ungate, the controller is
reset. Saying this, I will double check Dove's reset value but looks
like reset mess has been fixed in that later SoC.
> Our systems write the value 0x00638488 to PSC1.
>
> I looked at patching mv643xx_eth, but ran into the same complexity you
> did, it isn't clear what variants of this IP block have the
> register/etc.
For Orion SoCs it is quite clear to me, with Gregory Clement and Thomas
Petazzoni we could also confirm if it does any harm there if we
unconditionally clear it. But for PPC system controllers I have no
idea...
>> + /* Kirkwood resets some registers on gated clocks. Especially
>> + * CLK125_BYPASS_EN must be cleared but is not available on
>> + * all other SoCs/System Controllers using this driver.
>> + */
>> + if (of_machine_is_compatible("marvell,kirkwood"))
>> + wrlp(mp, PORT_SERIAL_CONTROL1,
>> + rdlp(mp, PORT_SERIAL_CONTROL1)& ~CLK125_BYPASS_EN);
>
> of_machine_is_compatible seems heavy handed, I would expect this to be
> based on the compatible string of the ethernet node itself, not the
> machine??
I have no strong opinion about checking the machine compatible or have
an extra compatible string for Kirkwood ethernet. Both would work fine
and are checked once upon probe anyway.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
From: Sebastian Hesselbarth @ 2013-05-22 20:55 UTC (permalink / raw)
To: Simon Baatz
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <20130522203633.GA28394@schnuecks.de>
On 05/22/2013 10:36 PM, Simon Baatz wrote:
> Hi Sebastian,
>
> On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
>> With DT support for mv643xx_eth, board specific init for some boards now
>> is unneccessary. Remove those board files, Kconfig entries, and
>> corresponding entries in kirkwood_defconfig.
>>
>> Signed-off-by: Sebastian Hesselbarth<sebastian.hesselbarth@gmail.com>
>> ---
>> Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
>> the lock-up is not caused by accessing clock gating registers but rather
>> non-existent device registers. This will be addressed by dtsi separation
>> for kirkwood and bobcat SoC variants.
>>
>> Changelog:
>> v3->v4:
>> - remove more boards that don't require board specific setup
>>
...
> We still have:
>
> static const char * const kirkwood_dt_board_compat[] = {
> "globalscale,dreamplug",
> "globalscale,guruplug",
> "dlink,dns-320",
> "dlink,dns-325",
> "iom,iconnect",
> "raidsonic,ib-nas62x0",
> "qnap,ts219",
> "seagate,dockstar",
> "seagate,goflexnet",
> "buffalo,lsxl",
> "iom,ix2-200",
> "keymile,km_kirkwood",
> "lacie,cloudbox",
> "lacie,inetspace_v2",
> "lacie,netspace_lite_v2",
> "lacie,netspace_max_v2",
> "lacie,netspace_mini_v2",
> "lacie,netspace_v2",
> "mpl,cec4",
> "netgear,readynas-duo-v2",
> "plathome,openblocks-a6",
> "usi,topkick",
> "zyxel,nsa310",
> NULL
> };
>
> in that file. I think it does not make sense that we need to list
> boards here that can be described fully by DT. When adding such a
> board in the future, you will still need to adapt board-dt.c.
True, will remove the redundant compatible strings for v5.
Actually, if I am not missing something, all compatible strings except
"marvell,kirkwood" are redundant as long as board.dts append it
correctly.
> Should we remove the boards that you removed above here as well and
> add
>
> "marvell,kirkwood-88f6192",
> "marvell,kirkwood-88f6281",
> "marvell,kirkwood-88f6282",
> "marvell,kirkwood-88f6283",
> "marvell,kirkwood-88f6702",
> "marvell,kirkwood-98DX4122",
>
> or even just state "marvell,kirkwood"?
I would stick with "marvell,kirkwood" only. This is SoC init code and
we do not distinguish variants here at all.
Sebastian
^ permalink raw reply
* Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
From: Michael S. Tsirkin @ 2013-05-22 20:38 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-m32r-ja, kvm, Catalin Marinas, Will Deacon, David Howells,
linux-mm, Paul Mackerras, H. Peter Anvin, linux-arch,
linux-am33-list, Hirokazu Takata, x86, Ingo Molnar, Arnd Bergmann,
microblaze-uclinux, Chris Metcalf, rostedt, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, linux-kernel,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <20130521115734.GA9554@twins.programming.kicks-ass.net>
On Tue, May 21, 2013 at 01:57:34PM +0200, Peter Zijlstra wrote:
> On Sun, May 19, 2013 at 12:35:26PM +0300, Michael S. Tsirkin wrote:
> > > > --- a/include/linux/kernel.h
> > > > +++ b/include/linux/kernel.h
> > > > @@ -198,7 +198,6 @@ void might_fault(void);
> > > > #else
> > > > static inline void might_fault(void)
> > > > {
> > > > - might_sleep();
> > >
> > > This removes potential resched points for PREEMPT_VOLUNTARY -- was that
> > > intentional?
> >
> > No it's a bug. Thanks for pointing this out.
> > OK so I guess it should be might_sleep_if(!in_atomic())
> > and this means might_fault would have to move from linux/kernel.h to
> > linux/uaccess.h, since in_atomic() is in linux/hardirq.h
> >
> > Makes sense?
>
> So the only difference between PROVE_LOCKING and not should be the
> might_lock_read() thing; so how about something like this?
So the problem with the below is that might_fault is needed
in asm/uaccess.h.
I'm still trying various approaches but the dependencies there
are very complex.
> ---
> include/linux/kernel.h | 7 ++-----
> include/linux/uaccess.h | 26 ++++++++++++++++++++++++++
> mm/memory.c | 14 ++------------
> 3 files changed, 30 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e96329c..70812f4 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -194,12 +194,9 @@ extern int _cond_resched(void);
> })
>
> #ifdef CONFIG_PROVE_LOCKING
> -void might_fault(void);
> +void might_fault_lockdep(void);
> #else
> -static inline void might_fault(void)
> -{
> - might_sleep();
> -}
> +static inline void might_fault_lockdep(void) { }
> #endif
>
> extern struct atomic_notifier_head panic_notifier_list;
> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
> index 5ca0951..50a2cc9 100644
> --- a/include/linux/uaccess.h
> +++ b/include/linux/uaccess.h
> @@ -38,6 +38,32 @@ static inline void pagefault_enable(void)
> preempt_check_resched();
> }
>
> +static inline bool __can_fault(void)
> +{
> + /*
> + * Some code (nfs/sunrpc) uses socket ops on kernel memory while
> + * holding the mmap_sem, this is safe because kernel memory doesn't
> + * get paged out, therefore we'll never actually fault, and the
> + * below annotations will generate false positives.
> + */
> + if (segment_eq(get_fs(), KERNEL_DS))
> + return false;
> +
> + if (in_atomic() /* || pagefault_disabled() */)
> + return false;
> +
> + return true;
> +}
> +
> +static inline void might_fault(void)
> +{
> + if (!__can_fault())
> + return;
> +
> + might_sleep();
> + might_fault_lockdep();
> +}
> +
> #ifndef ARCH_HAS_NOCACHE_UACCESS
>
> static inline unsigned long __copy_from_user_inatomic_nocache(void *to,
> diff --git a/mm/memory.c b/mm/memory.c
> index 6dc1882..266610c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4211,19 +4211,9 @@ void print_vma_addr(char *prefix, unsigned long ip)
> }
>
> #ifdef CONFIG_PROVE_LOCKING
> -void might_fault(void)
> +void might_fault_lockdep(void)
> {
> /*
> - * Some code (nfs/sunrpc) uses socket ops on kernel memory while
> - * holding the mmap_sem, this is safe because kernel memory doesn't
> - * get paged out, therefore we'll never actually fault, and the
> - * below annotations will generate false positives.
> - */
> - if (segment_eq(get_fs(), KERNEL_DS))
> - return;
> -
> - might_sleep();
> - /*
> * it would be nicer only to annotate paths which are not under
> * pagefault_disable, however that requires a larger audit and
> * providing helpers like get_user_atomic.
> @@ -4231,7 +4221,7 @@ void might_fault(void)
> if (!in_atomic() && current->mm)
> might_lock_read(¤t->mm->mmap_sem);
> }
> -EXPORT_SYMBOL(might_fault);
> +EXPORT_SYMBOL(might_fault_lockdep);
> #endif
>
> #if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
^ permalink raw reply
* Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
From: Michael S. Tsirkin @ 2013-05-22 20:36 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-m32r-ja, kvm, Catalin Marinas, Will Deacon, David Howells,
linux-mm, Paul Mackerras, H. Peter Anvin, linux-arch,
linux-am33-list, Hirokazu Takata, x86, Ingo Molnar, Arnd Bergmann,
microblaze-uclinux, Chris Metcalf, rostedt, Thomas Gleixner,
linux-arm-kernel, Michal Simek, linux-m32r, linux-kernel,
Koichi Yasutake, linuxppc-dev
In-Reply-To: <20130516184041.GP19669@dyad.programming.kicks-ass.net>
On Thu, May 16, 2013 at 08:40:41PM +0200, Peter Zijlstra wrote:
> On Thu, May 16, 2013 at 02:16:10PM +0300, Michael S. Tsirkin wrote:
> > There are several ways to make sure might_fault
> > calling function does not sleep.
> > One is to use it on kernel or otherwise locked memory - apparently
> > nfs/sunrpc does this. As noted by Ingo, this is handled by the
> > migh_fault() implementation in mm/memory.c but not the one in
> > linux/kernel.h so in the current code might_fault() schedules
> > differently depending on CONFIG_PROVE_LOCKING, which is an undesired
> > semantical side effect.
> >
> > Another is to call pagefault_disable: in this case the page fault
> > handler will go to fixups processing and we get an error instead of
> > sleeping, so the might_sleep annotation is a false positive.
> > vhost driver wants to do this now in order to reuse socket ops
> > under a spinlock (and fall back on slower thread handler
> > on error).
>
> Are you using the assumption that spin_lock() implies preempt_disable() implies
> pagefault_disable()? Note that this assumption isn't valid for -rt where the
> spinlock becomes preemptible but we'll not disable pagefaults.
>
> > Address both issues by:
> > - dropping the unconditional call to might_sleep
> > from the fast might_fault code in linux/kernel.h
> > - checking for pagefault_disable() in the
> > CONFIG_PROVE_LOCKING implementation
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> > include/linux/kernel.h | 1 -
> > mm/memory.c | 14 +++++++++-----
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> > index e96329c..322b065 100644
> > --- a/include/linux/kernel.h
> > +++ b/include/linux/kernel.h
> > @@ -198,7 +198,6 @@ void might_fault(void);
> > #else
> > static inline void might_fault(void)
> > {
> > - might_sleep();
>
> This removes potential resched points for PREEMPT_VOLUNTARY -- was that
> intentional?
OK so I'm thinking of going back to this idea:
it has the advantage of being very simple,
and just might make some workloads faster
if they do lots of copy_XX_user in a loop.
Will have to be tested of course - anyone
has objections?
> > }
> > #endif
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 6dc1882..1b8327b 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -4222,13 +4222,17 @@ void might_fault(void)
> > if (segment_eq(get_fs(), KERNEL_DS))
> > return;
> >
> > - might_sleep();
> > /*
> > - * it would be nicer only to annotate paths which are not under
> > - * pagefault_disable, however that requires a larger audit and
> > - * providing helpers like get_user_atomic.
> > + * It would be nicer to annotate paths which are under preempt_disable
> > + * but not under pagefault_disable, however that requires a new flag
> > + * for differentiating between the two.
>
> -rt has this, pagefault_disable() doesn't change the preempt count but pokes
> at task_struct::pagefault_disable.
>
> > */
> > - if (!in_atomic() && current->mm)
> > + if (in_atomic())
> > + return;
> > +
> > + might_sleep();
> > +
> > + if (current->mm)
> > might_lock_read(¤t->mm->mmap_sem);
> > }
> > EXPORT_SYMBOL(might_fault);
> > --
> > MST
^ permalink raw reply
* Re: [PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
From: Simon Baatz @ 2013-05-22 20:36 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <1369154510-4927-12-git-send-email-sebastian.hesselbarth@gmail.com>
Hi Sebastian,
On Tue, May 21, 2013 at 06:41:49PM +0200, Sebastian Hesselbarth wrote:
> With DT support for mv643xx_eth, board specific init for some boards now
> is unneccessary. Remove those board files, Kconfig entries, and
> corresponding entries in kirkwood_defconfig.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed
> the lock-up is not caused by accessing clock gating registers but rather
> non-existent device registers. This will be addressed by dtsi separation
> for kirkwood and bobcat SoC variants.
>
> Changelog:
> v3->v4:
> - remove more boards that don't require board specific setup
>
> Cc: David Miller <davem@davemloft.net>
> Cc: Lennert Buytenhek <buytenh@wantstofly.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/configs/kirkwood_defconfig | 16 ----
> arch/arm/mach-kirkwood/Kconfig | 117 -------------------------
> arch/arm/mach-kirkwood/Makefile | 16 ----
> arch/arm/mach-kirkwood/board-dnskw.c | 7 --
> arch/arm/mach-kirkwood/board-dockstar.c | 32 -------
> arch/arm/mach-kirkwood/board-dreamplug.c | 35 --------
> arch/arm/mach-kirkwood/board-dt.c | 38 --------
> arch/arm/mach-kirkwood/board-goflexnet.c | 34 -------
> arch/arm/mach-kirkwood/board-guruplug.c | 33 -------
> arch/arm/mach-kirkwood/board-ib62x0.c | 29 ------
> arch/arm/mach-kirkwood/board-iconnect.c | 10 ---
> arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 34 -------
> arch/arm/mach-kirkwood/board-km_kirkwood.c | 44 ----------
> arch/arm/mach-kirkwood/board-lsxl.c | 16 ----
> arch/arm/mach-kirkwood/board-mplcec4.c | 14 ---
> arch/arm/mach-kirkwood/board-ns2.c | 35 --------
> arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 ------
> arch/arm/mach-kirkwood/board-readynas.c | 6 --
> arch/arm/mach-kirkwood/board-ts219.c | 13 ---
> arch/arm/mach-kirkwood/board-usi_topkick.c | 29 ------
> 20 files changed, 584 deletions(-)
> delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c
> delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c
> delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c
> delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c
> delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c
> delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c
> delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c
> delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c
> delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c
> delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c
>
...
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index 8db388a..a86b41c 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -104,59 +104,21 @@ static void __init kirkwood_dt_init(void)
> kexec_reinit = kirkwood_enable_pcie;
> #endif
>
> - if (of_machine_is_compatible("globalscale,dreamplug"))
> - dreamplug_init();
> -
> - if (of_machine_is_compatible("globalscale,guruplug"))
> - guruplug_dt_init();
> -
> if (of_machine_is_compatible("dlink,dns-kirkwood"))
> dnskw_init();
>
> - if (of_machine_is_compatible("iom,iconnect"))
> - iconnect_init();
> -
> - if (of_machine_is_compatible("raidsonic,ib-nas62x0"))
> - ib62x0_init();
> -
> if (of_machine_is_compatible("qnap,ts219"))
> qnap_dt_ts219_init();
>
> - if (of_machine_is_compatible("seagate,dockstar"))
> - dockstar_dt_init();
> -
> - if (of_machine_is_compatible("seagate,goflexnet"))
> - goflexnet_init();
> -
> if (of_machine_is_compatible("buffalo,lsxl"))
> lsxl_init();
>
> - if (of_machine_is_compatible("iom,ix2-200"))
> - iomega_ix2_200_init();
> -
> - if (of_machine_is_compatible("keymile,km_kirkwood"))
> - km_kirkwood_init();
> -
> - if (of_machine_is_compatible("lacie,cloudbox") ||
> - of_machine_is_compatible("lacie,inetspace_v2") ||
> - of_machine_is_compatible("lacie,netspace_lite_v2") ||
> - of_machine_is_compatible("lacie,netspace_max_v2") ||
> - of_machine_is_compatible("lacie,netspace_mini_v2") ||
> - of_machine_is_compatible("lacie,netspace_v2"))
> - ns2_init();
> -
> if (of_machine_is_compatible("mpl,cec4"))
> mplcec4_init();
>
> if (of_machine_is_compatible("netgear,readynas-duo-v2"))
> netgear_readynas_init();
>
> - if (of_machine_is_compatible("plathome,openblocks-a6"))
> - openblocks_a6_init();
> -
> - if (of_machine_is_compatible("usi,topkick"))
> - usi_topkick_init();
> -
> of_platform_populate(NULL, kirkwood_dt_match_table, NULL, NULL);
> }
We still have:
static const char * const kirkwood_dt_board_compat[] = {
"globalscale,dreamplug",
"globalscale,guruplug",
"dlink,dns-320",
"dlink,dns-325",
"iom,iconnect",
"raidsonic,ib-nas62x0",
"qnap,ts219",
"seagate,dockstar",
"seagate,goflexnet",
"buffalo,lsxl",
"iom,ix2-200",
"keymile,km_kirkwood",
"lacie,cloudbox",
"lacie,inetspace_v2",
"lacie,netspace_lite_v2",
"lacie,netspace_max_v2",
"lacie,netspace_mini_v2",
"lacie,netspace_v2",
"mpl,cec4",
"netgear,readynas-duo-v2",
"plathome,openblocks-a6",
"usi,topkick",
"zyxel,nsa310",
NULL
};
in that file. I think it does not make sense that we need to list
boards here that can be described fully by DT. When adding such a
board in the future, you will still need to adapt board-dt.c.
Should we remove the boards that you removed above here as well and
add
"marvell,kirkwood-88f6192",
"marvell,kirkwood-88f6281",
"marvell,kirkwood-88f6282",
"marvell,kirkwood-88f6283",
"marvell,kirkwood-88f6702",
"marvell,kirkwood-98DX4122",
or even just state "marvell,kirkwood"?
- Simon
^ permalink raw reply
* Re: [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
From: Jason Gunthorpe @ 2013-05-22 20:16 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, linux-kernel, Lennert Buytenhek,
netdev, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <1369253042-15082-2-git-send-email-sebastian.hesselbarth@gmail.com>
On Wed, May 22, 2013 at 10:04:02PM +0200, Sebastian Hesselbarth wrote:
> Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
> MAC address register contents on clock gating but also some important
> registers are reset to values that would break ethernet. This patch
FWIW, we found that the bootloader has to write to PSC1, the driver
doesn't work with the power on/reset value of the register. So I think
it is safe to assume that all kirkwood bootloaders alter the value.
Our systems write the value 0x00638488 to PSC1.
I looked at patching mv643xx_eth, but ran into the same complexity you
did, it isn't clear what variants of this IP block have the
register/etc.
> + /* Kirkwood resets some registers on gated clocks. Especially
> + * CLK125_BYPASS_EN must be cleared but is not available on
> + * all other SoCs/System Controllers using this driver.
> + */
> + if (of_machine_is_compatible("marvell,kirkwood"))
> + wrlp(mp, PORT_SERIAL_CONTROL1,
> + rdlp(mp, PORT_SERIAL_CONTROL1) & ~CLK125_BYPASS_EN);
of_machine_is_compatible seems heavy handed, I would expect this to be
based on the compatible string of the ethernet node itself, not the
machine??
Jason
^ permalink raw reply
* [PATCH 2/2] net: mv643xx_eth: proper initialization for Kirkwood SoCs
From: Sebastian Hesselbarth @ 2013-05-22 20:04 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <1369253042-15082-1-git-send-email-sebastian.hesselbarth@gmail.com>
Ethernet controllers found on Kirkwood SoCs not only suffer from loosing
MAC address register contents on clock gating but also some important
registers are reset to values that would break ethernet. This patch
clears the CLK125_BYPASS_EN bit for DT enabled Kirkwood only by using
of_machine_is_compatible() instead of #ifdefs. Non-DT Kirkwood is not
affected as it installs a clock gating workaround because of the MAC
address issue above. Other Orion SoCs do not suffer from register reset,
do not have the bit in question, or do not have the register at all.
Moreover, system controllers on PPC using this driver should also be
protected from clearing that bit.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Note: In contrast to the reset value of 0 for CLK125_BYPASS_EN bit as
stated in Kirkwood datasheet, we confirmed that reset value is 1 instead.
Either datasheet is wrong about it, there is some post-boot self-check or
BootROM flips that bit.
Cc: David Miller <davem@davemloft.net>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index f2c229c..d9ad8c7 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -119,6 +119,8 @@ static char mv643xx_eth_driver_version[] = "1.4";
#define LINK_UP 0x00000002
#define TXQ_COMMAND 0x0048
#define TXQ_FIX_PRIO_CONF 0x004c
+#define PORT_SERIAL_CONTROL1 0x004c
+#define CLK125_BYPASS_EN 0x00000010
#define TX_BW_RATE 0x0050
#define TX_BW_MTU 0x0058
#define TX_BW_BURST 0x005c
@@ -2843,6 +2845,14 @@ static int mv643xx_eth_probe(struct platform_device *pdev)
mp->dev = dev;
+ /* Kirkwood resets some registers on gated clocks. Especially
+ * CLK125_BYPASS_EN must be cleared but is not available on
+ * all other SoCs/System Controllers using this driver.
+ */
+ if (of_machine_is_compatible("marvell,kirkwood"))
+ wrlp(mp, PORT_SERIAL_CONTROL1,
+ rdlp(mp, PORT_SERIAL_CONTROL1) & ~CLK125_BYPASS_EN);
+
/*
* Start with a default rate, and if there is a clock, allow
* it to override the default.
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/2] ARM: kirkwood: proper retain MAC address workaround on DT ethernet
From: Sebastian Hesselbarth @ 2013-05-22 20:04 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, linux-arm-kernel,
linuxppc-dev, David Miller, Lennert Buytenhek
In-Reply-To: <1369154510-4927-1-git-send-email-sebastian.hesselbarth@gmail.com>
Kirkwood ethernet controllers suffer from loosing MAC register content
on gated clocks. In the past this was prevented by not gating the ethernet
controller clocks. With DT support for mv643xx_eth and corresponding
nodes available, a different approach is more reasonable.
This patch replaces the former clock gating workaround by parsing the
ethernet controller nodes for *invalid* MAC addresses and overwrites
the local-mac-address property with MAC register contents early. The
clock can now properly gated in modular mv643xx_eth and DT agnostic
boot loader scenarios because mv643xx_eth will find the stored MAC
in the corresponding MAC address property.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Cc: David Miller <davem@davemloft.net>
Cc: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: netdev@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/mach-kirkwood/board-dt.c | 67 +++++++++++++++++++++++++++++--------
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
index a86b41c..0aad9f7 100644
--- a/arch/arm/mach-kirkwood/board-dt.c
+++ b/arch/arm/mach-kirkwood/board-dt.c
@@ -13,6 +13,8 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/of.h>
+#include <linux/of_address.h>
+#include <linux/of_net.h>
#include <linux/of_platform.h>
#include <linux/clk-provider.h>
#include <linux/clk/mvebu.h>
@@ -31,6 +33,56 @@ static struct of_device_id kirkwood_dt_match_table[] __initdata = {
};
/*
+ * Kirkwood ethernet controllers suffer from loosing the MAC address
+ * register content on gated clocks. Rather than always ungate the
+ * clocks, we get the MAC address early and put it into DT for those
+ * boot loaders that don't provide a valid MAC address property.
+ */
+#define ETH_MAC_ADDR_L(n) (0x400 + ((n) * 0x400) + 0x14)
+#define ETH_MAC_ADDR_H(n) (0x400 + ((n) * 0x400) + 0x18)
+
+static void __init kirkwood_dt_eth_quirk(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, "marvell,orion-eth") {
+ struct device_node *pnp;
+ void __iomem *base;
+
+ if (!of_device_is_available(np))
+ continue;
+
+ base = of_iomap(np, 0);
+ if (!base)
+ continue;
+
+ for_each_available_child_of_node(np, pnp) {
+ const void *mac_addr;
+ struct property *p;
+ u32 n, reg[2];
+
+ mac_addr = of_get_mac_address(pnp);
+ if (mac_addr)
+ continue;
+
+ p = of_find_property(pnp, "local-mac-address", NULL);
+ if (!p || p->length != 6)
+ continue;
+
+ if (of_property_read_u32(pnp, "reg", &n))
+ continue;
+
+ reg[0] = cpu_to_be32(readl(base + ETH_MAC_ADDR_H(n)));
+ reg[1] = cpu_to_be32(readl(base +
+ ETH_MAC_ADDR_L(n)) << 16);
+ memcpy((void *)p->value, reg, 6);
+ }
+
+ iounmap(base);
+ }
+}
+
+/*
* There are still devices that doesn't know about DT yet. Get clock
* gates here and add a clock lookup alias, so that old platform
* devices still work.
@@ -42,7 +94,6 @@ static void __init kirkwood_legacy_clk_init(void)
struct device_node *np = of_find_compatible_node(
NULL, NULL, "marvell,kirkwood-gating-clock");
struct of_phandle_args clkspec;
- struct clk *clk;
clkspec.np = np;
clkspec.args_count = 1;
@@ -58,19 +109,6 @@ static void __init kirkwood_legacy_clk_init(void)
clkspec.args[0] = CGC_BIT_SDIO;
orion_clkdev_add(NULL, "mvsdio",
of_clk_get_from_provider(&clkspec));
-
- /*
- * The ethernet interfaces forget the MAC address assigned by
- * u-boot if the clocks are turned off. Until proper DT support
- * is available we always enable them for now.
- */
- clkspec.args[0] = CGC_BIT_GE0;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
-
- clkspec.args[0] = CGC_BIT_GE1;
- clk = of_clk_get_from_provider(&clkspec);
- clk_prepare_enable(clk);
}
static void __init kirkwood_of_clk_init(void)
@@ -97,6 +135,7 @@ static void __init kirkwood_dt_init(void)
/* Setup root of clk tree */
kirkwood_of_clk_init();
+ kirkwood_dt_eth_quirk();
kirkwood_cpuidle_init();
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Sebastian Hesselbarth @ 2013-05-22 19:52 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <20130522174815.GI31290@titan.lakedaemon.net>
On 05/22/2013 07:48 PM, Jason Cooper wrote:
> On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
>> On 05/22/2013 07:35 PM, Jason Cooper wrote:
>>> On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
>>>> Just tested on Dockstar with gated clocks and modular DT mv643xx_eth.
>>>>
>>>> Will append to the DT mv643xx_eth patch set if a v5 will be required
>>>> or as single patch prior Jason C taking in the ARM part of it
>>>> otherwise.
>>>
>>> Please post, in-reply-to v4 is fine.
>>
>> Hmm, maybe a little bit too early. While restoring the MAC address now
>> works, another bug arises which I guess is related with phy setup
>> and aneg.
>>
>> Will investigate and update patch set accordingly.
Ok, have it working now by properly clearing CLK125_BYPASS_EN bit in
PORT_SERIAL_CTRL1 register for Kirkwood only. I have two more patches
ready that I will post as single patches in reply to v4.
If David gives his ACK for the patch set and names a branch to base it
on, I will send a v5 including all patches.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Jason Cooper @ 2013-05-22 18:58 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <519D1485.50801@gmail.com>
On Wed, May 22, 2013 at 08:55:01PM +0200, Sebastian Hesselbarth wrote:
> On 05/22/2013 08:49 PM, Jason Cooper wrote:
> >On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote:
> >>On 05/22/2013 07:48 PM, Jason Cooper wrote:
> >>>On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
> >>>>Hmm, maybe a little bit too early. While restoring the MAC address now
> >>>>works, another bug arises which I guess is related with phy setup
> >>>>and aneg.
> >>>>
> >>>>Will investigate and update patch set accordingly.
> >>>
> >>>Cool, chances are, we should be able to take that patch in by itself for
> >>>this merge window...
> >>
> >>Which patch do you mean? The local-mac-address workaround will only be
> >>available for DT mv643xx_eth because it uses the DT node to store the
> >>MAC.
> >
> >I thought you were replacing the unconditional ethernet clock grabbing
> >with reading the mac from the registers and updating the dtb? In
> >mach-kirkwood/board-dt.c?
>
> True. But there is no node for ethernet controllers in kirkwood.dtsi
> yet. It will be there with mv643xx_eth DT patches applied and that is
> when the corresponding replacement patch should also be taken in.
>
> I was just confused about your referral to the merge window, because I
> guess it is up to David Miller to decide when/whether to take
> mv643xx_eth patches in.
Ahh, no, that was me. I was contemplating adding the dt entries in this
merge window at one point and must've got my wires crossed. Sorry for
the confusion.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Sebastian Hesselbarth @ 2013-05-22 18:55 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <20130522184936.GK31290@titan.lakedaemon.net>
On 05/22/2013 08:49 PM, Jason Cooper wrote:
> On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote:
>> On 05/22/2013 07:48 PM, Jason Cooper wrote:
>>> On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
>>>> Hmm, maybe a little bit too early. While restoring the MAC address now
>>>> works, another bug arises which I guess is related with phy setup
>>>> and aneg.
>>>>
>>>> Will investigate and update patch set accordingly.
>>>
>>> Cool, chances are, we should be able to take that patch in by itself for
>>> this merge window...
>>
>> Which patch do you mean? The local-mac-address workaround will only be
>> available for DT mv643xx_eth because it uses the DT node to store the
>> MAC.
>
> I thought you were replacing the unconditional ethernet clock grabbing
> with reading the mac from the registers and updating the dtb? In
> mach-kirkwood/board-dt.c?
True. But there is no node for ethernet controllers in kirkwood.dtsi
yet. It will be there with mv643xx_eth DT patches applied and that is
when the corresponding replacement patch should also be taken in.
I was just confused about your referral to the merge window, because I
guess it is up to David Miller to decide when/whether to take
mv643xx_eth patches in.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Sebastian Hesselbarth @ 2013-05-22 18:51 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <20130522182448.GA17206@obsidianresearch.com>
On 05/22/2013 08:24 PM, Jason Gunthorpe wrote:
> On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
>> Not neccessary anyway, after talking Jason C in a Kirkwood-only
>> workaround I prepared a patch that reads mac address registers early
>> and stores it in the local-mac-address property.
>
> That sounds great, but, FWIW, our bootloaders don't set the MAC
> address registers. Does the work around only trigger if the
> local-mac-address property is 0?
I already thought about bootloaders not setting the register, but I will
not start parsing 1001 places for a valid MAC only for those. Also
reading the MAC address registers is default behavior of mv643xx_eth if
no MAC address is passed through platform_data.
But you are right, there is plenty of sanity checks in the workaround to
ensure that local-mac-address is only overwritten by it when
- you are on DT
- there is no valid MAC address in that node (of_get_mac_address)
- there is a local-mac-address property with a length of 6 bytes
So this workaround only applies on DT booted kernels with no mac set in
DT.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Jason Cooper @ 2013-05-22 18:49 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <519D1204.4090701@gmail.com>
On Wed, May 22, 2013 at 08:44:20PM +0200, Sebastian Hesselbarth wrote:
> On 05/22/2013 07:48 PM, Jason Cooper wrote:
> >On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
> >>Hmm, maybe a little bit too early. While restoring the MAC address now
> >>works, another bug arises which I guess is related with phy setup
> >>and aneg.
> >>
> >>Will investigate and update patch set accordingly.
> >
> >Cool, chances are, we should be able to take that patch in by itself for
> >this merge window...
>
> Which patch do you mean? The local-mac-address workaround will only be
> available for DT mv643xx_eth because it uses the DT node to store the
> MAC.
I thought you were replacing the unconditional ethernet clock grabbing
with reading the mac from the registers and updating the dtb? In
mach-kirkwood/board-dt.c?
confused. :-/
Jason.
^ permalink raw reply
* Re: Build regressions/improvements in v3.10-rc2
From: Geert Uytterhoeven @ 2013-05-22 18:36 UTC (permalink / raw)
To: Linux Kernel Development; +Cc: Linux/PPC Development
In-Reply-To: <alpine.DEB.2.00.1305222034040.25309@ayla.of.borg>
On Wed, 22 May 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.10-rc2 to v3.10-rc1[3], the summaries are:
> - build errors: +2/-13
One false positive due to a line concatenation, and
+ error: drivers/built-in.o: undefined reference to `il_pm_ops': => .data+0x51ce4)
powerpc-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/6246/ (120 out of 118 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/6218/ (all 118 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Sebastian Hesselbarth @ 2013-05-22 18:44 UTC (permalink / raw)
To: Jason Cooper
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <20130522174815.GI31290@titan.lakedaemon.net>
On 05/22/2013 07:48 PM, Jason Cooper wrote:
> On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
>> Hmm, maybe a little bit too early. While restoring the MAC address now
>> works, another bug arises which I guess is related with phy setup
>> and aneg.
>>
>> Will investigate and update patch set accordingly.
>
> Cool, chances are, we should be able to take that patch in by itself for
> this merge window...
Which patch do you mean? The local-mac-address workaround will only be
available for DT mv643xx_eth because it uses the DT node to store the
MAC.
Anyway, I found the bit that caused the other issue. It is the
Clk125_Bypass_En bit in PORT_SERIAL_CONTROL1 register. What bothers me
about it is:
- Only Dove and Kirkwood have the bit, MV78x00 doesn't have it, Orion5x
doesn't have the register at all. With ppc mv64x60 I can only guess,
but think it is like in Orion5x.
- Reset value of that bit should be 0, but after gating clock on
Kirkwood it is set to 1 causing wrong port clock to be selected.
Also Thomas Petazzoni confirmed that it is set after reset so
either FS is wrong about it or BootROM messes with it.
- Kirkwood and Dove FS tell me that port link must be down when you
change the bit.
As I can't be sure about how mv643xx_eth will behave on other platforms
except Kirkwood and Dove when writing that register, I tend to force
that bit to zero in the driver but only for those two by #ifdefs.
Sebastian
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Jason Gunthorpe @ 2013-05-22 18:24 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, Jason Cooper, netdev, linux-kernel, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <519D0143.1000203@gmail.com>
On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
> Not neccessary anyway, after talking Jason C in a Kirkwood-only
> workaround I prepared a patch that reads mac address registers early
> and stores it in the local-mac-address property.
That sounds great, but, FWIW, our bootloaders don't set the MAC
address registers. Does the work around only trigger if the
local-mac-address property is 0?
Jason
^ permalink raw reply
* Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
From: Jason Cooper @ 2013-05-22 17:48 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Andrew Lunn, netdev, linux-kernel, Jason Gunthorpe, tiejun.chen,
Lennert Buytenhek, linuxppc-dev, David Miller, linux-arm-kernel
In-Reply-To: <519D038C.9000605@gmail.com>
On Wed, May 22, 2013 at 07:42:36PM +0200, Sebastian Hesselbarth wrote:
> On 05/22/2013 07:35 PM, Jason Cooper wrote:
> >On Wed, May 22, 2013 at 07:32:51PM +0200, Sebastian Hesselbarth wrote:
> >>On 05/22/2013 06:59 PM, Jason Gunthorpe wrote:
> >>>On Wed, May 22, 2013 at 09:10:10AM -0400, Jason Cooper wrote:
> >>>>iirc, our solution to this was to parse the ATAGs for the mac addr and
> >>>>update the appended dtb. This way, module load and unload would work
> >>>>without loosing the mac address. I believe Jason Gunthorpe has a patch
> >>>>to atags_to_fdt() for this... This should allow us to get rid of the
> >>>>clocks hack.
> >>>
> >>>Sorry, no, we don't use ATAGs here, our platforms start the kernel
> >>>with a correct DTB that has the correct mac address to use. My patch
> >>>was to have the driver accept it, and I think Sebastian has already
> >>>got that functionality...
> >>
> >>Not neccessary anyway, after talking Jason C in a Kirkwood-only
> >>workaround I prepared a patch that reads mac address registers early
> >>and stores it in the local-mac-address property.
> >
> >Sweet!
> >
> >>Just tested on Dockstar with gated clocks and modular DT mv643xx_eth.
> >>
> >>Will append to the DT mv643xx_eth patch set if a v5 will be required
> >>or as single patch prior Jason C taking in the ARM part of it
> >>otherwise.
> >
> >Please post, in-reply-to v4 is fine.
>
> Hmm, maybe a little bit too early. While restoring the MAC address now
> works, another bug arises which I guess is related with phy setup
> and aneg.
>
> Will investigate and update patch set accordingly.
Cool, chances are, we should be able to take that patch in by itself for
this merge window...
thx,
Jason.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox