From: "Kamlakant Patel" <redacted>
Date: Mon, 12 Nov 2012 15:34:46 +0530
On Thu, Nov 08, 2012 at 01:57:54AM -0500, David Miller wrote:
quoted
From: "Kamlakant Patel" <redacted>
Date: Thu, 8 Nov 2012 12:16:28 +0530
quoted
smsc driver is disabled in our bootloader and it is not changing the
state of the smsc registers at any stage, so it is not a bootloader
issue.
What puts that chip into a non-default byte swapping mode then?
This is a property of the XLP GBU (IO bus flash like devices). A 32-bit
read/write will be split into two 16-bit operations, and when the XLP is
in big-endian mode, we get the lower 16-bit ends up in bits 31-16 and the
upper 16-bit in bits 15-0.
The code before commit 3ac3546e worked because the driver saw that the registers
are word swapped (not byte swapped) and programmed the WORD_SWAP register
first (before any other register operations).
Ok, fair enough. Someone can resubmit the patch, and I'll apply it,
but I still very much dislike this situation.
Please make sure there is a very verbose comment added to the code,
and a similarly verbose commit message for the patch explaining
exactly how the chip gets into this state and why we have to solve
the problem this way.
Thanks.
Don't forget to push so that the HW guys update the datasheet as Linus W mentioned.
BR
Robert
-----Original Message-----
From: David Miller [mailto:davem@davemloft.net]
Sent: den 12 november 2012 20:40
To: kamlakant.patel@broadcom.com
Cc: steve@shawell.net; linus.walleij@linaro.org; Robert MARKLUND; netdev@vger.kernel.org
Subject: Re: net/smsc911x: problems after commit 3ac3546e [Always wait for the chip to be ready]
From: "Kamlakant Patel" <redacted>
Date: Mon, 12 Nov 2012 15:34:46 +0530
quoted
On Thu, Nov 08, 2012 at 01:57:54AM -0500, David Miller wrote:
quoted
From: "Kamlakant Patel" <redacted>
Date: Thu, 8 Nov 2012 12:16:28 +0530
quoted
smsc driver is disabled in our bootloader and it is not changing the
state of the smsc registers at any stage, so it is not a bootloader
issue.
What puts that chip into a non-default byte swapping mode then?
This is a property of the XLP GBU (IO bus flash like devices). A 32-bit
read/write will be split into two 16-bit operations, and when the XLP is
in big-endian mode, we get the lower 16-bit ends up in bits 31-16 and the
upper 16-bit in bits 15-0.
The code before commit 3ac3546e worked because the driver saw that the registers
are word swapped (not byte swapped) and programmed the WORD_SWAP register
first (before any other register operations).
Ok, fair enough. Someone can resubmit the patch, and I'll apply it,
but I still very much dislike this situation.
Please make sure there is a very verbose comment added to the code,
and a similarly verbose commit message for the patch explaining
exactly how the chip gets into this state and why we have to solve
the problem this way.
Thanks.