* [PATCH] ARM: at91: smc: bug fix in sam9_smc_cs_read()
From: Kevin Hilman @ 2014-01-14 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389279714-30873-1-git-send-email-nicolas.ferre@atmel.com>
Nicolas Ferre <nicolas.ferre@atmel.com> writes:
> From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>
> There was a copy/paste error when reading the nwe_pulse value.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> Acked-by: Boris BREZILLON <b.brezillon@overkiz.com>
> Cc: stable <stable@vger.kernel.org> # 3.3
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Arnd, Olof, Kevin,
>
> This is a little fix that I have just received. As the "fixes" colletion is
> certainly closed for 3.13, I would like to include this one in the
> "fixes-non-critical" topic for 3.14.
>
> For the time being, I only have this one, so It can be convenient if you take
> this fix as a patch instead of a pull-request.
Applied to fixes-non-critical, and merged into for-next.
Thanks,
Kevin
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Bjørn Mork @ 2014-01-14 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114170719.GA12126@xanatos>
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> On Sun, Jan 12, 2014 at 10:36:56PM +0100, Arnaud Ebalard wrote:
>
>> arno at natisbad.org (Arnaud Ebalard) writes:
>>
>> 2) on current 3.13.0-rc7 kernel (w/ Bj?rn patch applied just in case), I
>
> Which patch are you referring to?
I wondered about that too at first :-)
But luckily I don't work that much, and the reference to the ASIX
AX88179 made it clearer. I believe it must have been this patch:
https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=fdc3452cd2c7b2bfe0f378f92123f4f9a98fa2bd
Bj?rn
^ permalink raw reply
* [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
From: Nishanth Menon @ 2014-01-14 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA3XUr2cnF_rxMYvZfjBx22Sa8YE45o_qUU8GNoerQwhWqxhNQ@mail.gmail.com>
On Tue, Jan 14, 2014 at 11:35 AM, Victor Kamensky
<victor.kamensky@linaro.org> wrote:
>
> When BE kernel is built Makefile does take of compiling code in BE
> mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set.
Agreed, and I assume you cannot instead switch to LE mode when
entering assembly assuming LE?
The reason I ask this is - most of our development is NOT in BE mode.
we will continue to manipulate and add assembly - AM335x, DRA7/OMAP5
etc.. and obviously not every code change will indulge in ensuring
right markers will be in place.
by ensuring readl_relaxed handles the variations, you have ensured
that I dont need to care about drivers other than to ensure they use
_relaxed variants. in the case of assembly, this does not seem long
term manageable.
>
>> is the idea of BE build meant to deal with having a single BE kernel
>> build work for all platforms (including LE ones)?
>
> Sort of. The idea here to run BE image on OMAP4 chip, with
> kernel that would deals with LE periphery correctly, but ARM
> core run in BE with special kernel that compiled for BE case (i.e
> CONFIG_CPU_BIG_ENDIAN is set).
I still dont get the usecase - other than "hey, we do this coz we can
do it!".. I mean, yep, it sounds great and all.. but 4 years down the
line, is this still going to work? is this going to be interesting
careabout? or we are just maintaining additional code for a passing
fancy or proof-of-concept?
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 4/6] ARM: DTS: tegra: add the DFLL IP block to the T114 SoC file
From: Stephen Warren @ 2014-01-14 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D4D314.3000208@nvidia.com>
On 01/13/2014 11:03 PM, Paul Walmsley wrote:
> On 12/19/2013 04:05 PM, Stephen Warren wrote:
>> On 12/19/2013 05:49 AM, Paul Walmsley wrote:
>>> Add basic DT bindings for the DFLL IP block for the NVIDIA Tegra114 SoC.
>>> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-dfll.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-dfll.txt
>>> +- clock-names : Must contain an array of strings, one per 'clocks'
>>> + two-cell array. The position in the array of these
>> clock-names defines the set of entries in clocks, not the other way around.
>
> Hmm. If one refers to the DT clock binding documentation, it lists the
> 'clock-names' property as optional, and the 'clocks' property as mandatory:
>
> -----
>
> |==Clock consumers==
>
> Required properties:
> clocks: List of phandle and clock specifier pairs, one pair
> for each clock input to the device. Note: if the
> clock provider specifies '0' for #clock-cells, then
> only the phandle portion of the pair will appear.
>
> Optional properties:
> clock-names: List of clock input name strings sorted in the same
> order as the clocks property. Consumers drivers
> will use clock-names to match clock input names
> with clocks specifiers.
>
> -----
> |
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/clock-bindings.txt#n47
>
> Considering that of_clk_get() doesn't require names, it certainly
> appears to be the way that the original patch described it (modulo the
> bit about 'cells'; which has been fixed.)
If the binding defines that clock must exist at certain indices in the
clock property, and clock-names isn't used, then the clocks property
defines which clocks must exist.
However, if the binding is defining clock names, then the clock-names
property is the master that defines which clocks exist. In this case,
the index of entries in the clocks property is undefined by the binding;
it must simply match the clock-names property, which can be arbitrarily
ordered by the user.
Since this is a new binding, we should use the clock-names style to
ensure easy future backwards-compatible changes.
^ permalink raw reply
* [PATCH] ARM: OMAP4: sleep: byteswap data for big-endian
From: Victor Kamensky @ 2014-01-14 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D55CE5.1060902@ti.com>
Hi Nishanth,
On 14 January 2014 07:51, Nishanth Menon <nm@ti.com> wrote:
> On 01/14/2014 05:14 AM, Taras Kondratiuk wrote:
>> On 13 January 2014 17:23, Nishanth Menon <nm@ti.com> wrote:
>>> On 01/13/2014 09:03 AM, Taras Kondratiuk wrote:
>>>> From: Victor Kamensky <victor.kamensky@linaro.org>
>>>>
>>>> Assembler functions defined in sleep44xx.S need to byteswap values
>>>> after read / before write from h/w register if code compiled in big
>>>> endian mode. Simple change to do 'rev x, x' before str instruction
>>>> and after ldr instruction that deals with h/w registers.
>>>>
>>>> Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org>
>>>> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
>>>> ---
>>>> This is a part of RFC series [1].
>>>> Based on v3.13-rc8.
>>>>
>>>> [1] http://www.spinics.net/lists/linux-omap/msg99927.html
>>>>
>>>> arch/arm/mach-omap2/sleep44xx.S | 17 +++++++++++++++++
>>>> 1 file changed, 17 insertions(+)
>>>>
>>>
>>> OMAP4 is LE, and if there is a gcc flag for the same, is'nt it cleaner
>>> to deal with it in Makefile rather than trying to make an assembly
>>> meant only for LE by force building it for BE?
>>
>> Hi Nishanth
>> I'm not sure I got your point.
>> Do you propose to build this file as LE while the rest of kernel is BE?
>>
> I dont see why I should deal with the BE macro for every code change
> we have in omap4,am335x assembly. The hardware is LE and wont change
> just coz you are building it for BE. So I dont get the rationale for
> changing the assembly here - yes, if the assembly can be maintained as
> LE only mode and the build handling be adequately handled in Makefile
> (similar to SMC handling), that would be the best.
ARM core is capable of running in LE or BE modes. Yes, OMAP
memory mapped periphery gives data in LE form. When core runs
in BE mode after reading h/w register it will byteswap it, also before
writing h/w register it byteswap it. In such way BE kernel can work
with LE periphery.
When it comes to C code that works with LE periphery, if correct
access functions are used like readl_relaxed and writel_relaxed
(vs __raw_readl and __raw_writel), the functions will take care of
the swaps. In case of asm files there is no other way than to insert
those byteswaps manually and conditionally - they will be enabled only
if kernel compiled in BE mode. The reason why it could be done only
manually is that load/store opcodes behavior changes when core
runs in BE mode (E bit set) in these case ldr/str treat memory as
big endian. So when LE periphery register is read/stored additional
byteswaps that compensate for it should be inserted.
When BE kernel is built Makefile does take of compiling code in BE
mode. I.e all proper flags like -mbig-endian and -Wl,--be8 will be set.
> is the idea of BE build meant to deal with having a single BE kernel
> build work for all platforms (including LE ones)?
Sort of. The idea here to run BE image on OMAP4 chip, with
kernel that would deals with LE periphery correctly, but ARM
core run in BE with special kernel that compiled for BE case (i.e
CONFIG_CPU_BIG_ENDIAN is set).
Thanks,
Victor
> --
> Regards,
> Nishanth Menon
^ permalink raw reply
* [PATCH 1/5] crypto: Fully restore ahash request before completing
From: Marek Vasut @ 2014-01-14 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140105232926.GA29518@gondor.apana.org.au>
On Monday, January 06, 2014 at 12:29:27 AM, Herbert Xu wrote:
> On Sun, Jan 05, 2014 at 04:33:21PM +0100, Marek Vasut wrote:
> > On Sunday, January 05, 2014 at 02:05:29 PM, Herbert Xu wrote:
> > > On Tue, Dec 10, 2013 at 08:26:19PM +0100, Marek Vasut wrote:
> > > > When finishing the ahash request, the ahash_op_unaligned_done() will
> > > > call complete() on the request. Yet, this will not call the correct
> > > > complete callback. The correct complete callback was previously
> > > > stored in the requests' private data, as seen in
> > > > ahash_op_unaligned(). This patch restores the correct complete
> > > > callback and .data field of the request before calling complete() on
> > > > it.
> > > >
> > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > > > Cc: David S. Miller <davem@davemloft.net>
> > > > Cc: Fabio Estevam <fabio.estevam@freescale.com>
> > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > Cc: linux-crypto at vger.kernel.org
> > >
> > > All patches applied. Thanks!
> >
> > Uh, I think this was not intended to happen! We still discuss this patch
> > will need rework, do we not?
>
> Please send your new fixes as incremental patches on top of this.
I sent a new set of patches and added a bit of documentation too. I am still
working on a better piece of documentation for writing crypto drivers now.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH 3/3] crypto: Simplify the ahash_finup implementation
From: Marek Vasut @ 2014-01-14 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389720829-5963-1-git-send-email-marex@denx.de>
The ahash_def_finup() can make use of the request save/restore functions,
thus make it so. This simplifies the code a little and unifies the code
paths.
Note that the same remark about free()ing the req->priv applies here, the
req->priv can only be free()'d after the original request was restored.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
---
crypto/ahash.c | 53 ++++++++++++++++++++---------------------------------
1 file changed, 20 insertions(+), 33 deletions(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 635cd49..561ebaf 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -350,20 +350,19 @@ static void ahash_def_finup_finish2(struct ahash_request *req, int err)
if (!err)
memcpy(priv->result, req->result,
crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- kzfree(priv);
}
-static void ahash_def_finup_done2(struct crypto_async_request *req, int err)
+static void ahash_def_finup_done2(struct crypto_async_request *areq, int err)
{
- struct ahash_request *areq = req->data;
- struct ahash_request_priv *priv = areq->priv;
- crypto_completion_t complete = priv->complete;
- void *data = priv->data;
+ struct ahash_request *req = areq->data;
+ struct crypto_async_request *data;
- ahash_def_finup_finish2(areq, err);
+ ahash_def_finup_finish2(req, err);
- complete(data, err);
+ ahash_restore_req(req);
+
+ data = req->base.data;
+ req->base.complete(data, err);
}
static int ahash_def_finup_finish1(struct ahash_request *req, int err)
@@ -380,39 +379,27 @@ out:
return err;
}
-static void ahash_def_finup_done1(struct crypto_async_request *req, int err)
+static void ahash_def_finup_done1(struct crypto_async_request *areq, int err)
{
- struct ahash_request *areq = req->data;
- struct ahash_request_priv *priv = areq->priv;
- crypto_completion_t complete = priv->complete;
- void *data = priv->data;
+ struct ahash_request *req = areq->data;
+ struct crypto_async_request *data;
- err = ahash_def_finup_finish1(areq, err);
+ err = ahash_def_finup_finish1(req, err);
+
+ ahash_restore_req(req);
- complete(data, err);
+ data = req->base.data;
+ req->base.complete(data, err);
}
static int ahash_def_finup(struct ahash_request *req)
{
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
- unsigned long alignmask = crypto_ahash_alignmask(tfm);
- unsigned int ds = crypto_ahash_digestsize(tfm);
- struct ahash_request_priv *priv;
-
- priv = kmalloc(sizeof(*priv) + ahash_align_buffer_size(ds, alignmask),
- (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
- GFP_KERNEL : GFP_ATOMIC);
- if (!priv)
- return -ENOMEM;
-
- priv->result = req->result;
- priv->complete = req->base.complete;
- priv->data = req->base.data;
+ int err;
- req->result = PTR_ALIGN((u8 *)priv->ubuf, alignmask + 1);
- req->base.complete = ahash_def_finup_done1;
- req->base.data = req;
- req->priv = priv;
+ err = ahash_save_req(req, ahash_def_finup_done1);
+ if (err)
+ return err;
return ahash_def_finup_finish1(req, tfm->update(req));
}
--
1.8.5.2
^ permalink raw reply related
* [PATCH 2/3] crypto: Pull out the functions to save/restore request
From: Marek Vasut @ 2014-01-14 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389720829-5963-1-git-send-email-marex@denx.de>
The functions to save original request within a newly adjusted request
and it's counterpart to restore the original request can be re-used by
more code in the crypto/ahash.c file. Pull these functions out from the
code so they're available.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
---
crypto/ahash.c | 112 +++++++++++++++++++++++++++++++++------------------------
1 file changed, 65 insertions(+), 47 deletions(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index 5ca8ede..635cd49 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -191,58 +191,14 @@ static inline unsigned int ahash_align_buffer_size(unsigned len,
return len + (mask & ~(crypto_tfm_ctx_alignment() - 1));
}
-static void ahash_op_unaligned_finish(struct ahash_request *req, int err)
-{
- struct ahash_request_priv *priv = req->priv;
-
- if (err == -EINPROGRESS)
- return;
-
- if (!err)
- memcpy(priv->result, req->result,
- crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-}
+static void ahash_op_unaligned_done(struct crypto_async_request *areq, int err);
-static void ahash_op_unaligned_done(struct crypto_async_request *areq, int err)
-{
- struct ahash_request *req = areq->data;
- struct ahash_request_priv *priv = req->priv;
- struct crypto_async_request *data;
-
- /*
- * Restore the original request, see ahash_op_unaligned() for what
- * goes where.
- *
- * The "struct ahash_request *req" here is in fact the "req.base"
- * from the ADJUSTED request from ahash_op_unaligned(), thus as it
- * is a pointer to self, it is also the ADJUSTED "req" .
- */
-
- /* First copy req->result into req->priv.result */
- ahash_op_unaligned_finish(req, err);
-
- /* Restore the original crypto request. */
- req->result = priv->result;
- req->base.complete = priv->complete;
- req->base.data = priv->data;
- req->priv = priv->priv;
-
- /* Free the req->priv.priv from the ADJUSTED request. */
- kzfree(priv);
-
- /* Complete the ORIGINAL request. */
- data = req->base.data;
- req->base.complete(data, err);
-}
-
-static int ahash_op_unaligned(struct ahash_request *req,
- int (*op)(struct ahash_request *))
+static int ahash_save_req(struct ahash_request *req, crypto_completion_t cplt)
{
struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
unsigned long alignmask = crypto_ahash_alignmask(tfm);
unsigned int ds = crypto_ahash_digestsize(tfm);
struct ahash_request_priv *priv;
- int err;
priv = kmalloc(sizeof(*priv) + ahash_align_buffer_size(ds, alignmask),
(req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
@@ -282,10 +238,72 @@ static int ahash_op_unaligned(struct ahash_request *req,
priv->priv = req->priv;
req->result = PTR_ALIGN((u8 *)priv->ubuf, alignmask + 1);
- req->base.complete = ahash_op_unaligned_done;
+ req->base.complete = cplt;
req->base.data = req;
req->priv = priv;
+ return 0;
+}
+
+static void ahash_restore_req(struct ahash_request *req)
+{
+ struct ahash_request_priv *priv = req->priv;
+
+ /* Restore the original crypto request. */
+ req->result = priv->result;
+ req->base.complete = priv->complete;
+ req->base.data = priv->data;
+ req->priv = priv->priv;
+
+ /* Free the req->priv.priv from the ADJUSTED request. */
+ kzfree(priv);
+}
+
+static void ahash_op_unaligned_finish(struct ahash_request *req, int err)
+{
+ struct ahash_request_priv *priv = req->priv;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ if (!err)
+ memcpy(priv->result, req->result,
+ crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
+}
+
+static void ahash_op_unaligned_done(struct crypto_async_request *areq, int err)
+{
+ struct ahash_request *req = areq->data;
+ struct crypto_async_request *data;
+
+ /*
+ * Restore the original request, see ahash_op_unaligned() for what
+ * goes where.
+ *
+ * The "struct ahash_request *req" here is in fact the "req.base"
+ * from the ADJUSTED request from ahash_op_unaligned(), thus as it
+ * is a pointer to self, it is also the ADJUSTED "req" .
+ */
+
+ /* First copy req->result into req->priv.result */
+ ahash_op_unaligned_finish(req, err);
+
+ ahash_restore_req(req);
+
+ /* Complete the ORIGINAL request. */
+ data = req->base.data;
+ req->base.complete(data, err);
+}
+
+static int ahash_op_unaligned(struct ahash_request *req,
+ int (*op)(struct ahash_request *))
+{
+ int err;
+
+ err = ahash_save_req(req, ahash_op_unaligned_done);
+ if (err)
+ return err;
+
err = op(req);
ahash_op_unaligned_finish(req, err);
--
1.8.5.2
^ permalink raw reply related
* [PATCH 1/3] crypto: Fix the pointer voodoo in unaligned ahash
From: Marek Vasut @ 2014-01-14 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389720829-5963-1-git-send-email-marex@denx.de>
Add documentation for the pointer voodoo that is happening in crypto/ahash.c
in ahash_op_unaligned(). This code is quite confusing, so add a beefy chunk
of documentation.
Moreover, make sure the mangled request is completely restored after finishing
this unaligned operation. This means restoring all of .result, .priv, .base.data
and .base.complete .
Also, remove the crypto_completion_t complete = ... line present in the
ahash_op_unaligned_done() function. This type actually declares a function
pointer, which is very confusing.
Finally, yet very important nonetheless, make sure the req->priv is free()'d
only after the original request is restored in ahash_op_unaligned_done().
The req->priv data must not be free()'d before that in ahash_op_unaligned_finish(),
since we would be accessing previously free()'d data in ahash_op_unaligned_done()
and cause corruption.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
---
crypto/ahash.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 54 insertions(+), 11 deletions(-)
diff --git a/crypto/ahash.c b/crypto/ahash.c
index a92dc38..5ca8ede 100644
--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -29,6 +29,7 @@
struct ahash_request_priv {
crypto_completion_t complete;
void *data;
+ void *priv;
u8 *result;
void *ubuf[] CRYPTO_MINALIGN_ATTR;
};
@@ -200,23 +201,38 @@ static void ahash_op_unaligned_finish(struct ahash_request *req, int err)
if (!err)
memcpy(priv->result, req->result,
crypto_ahash_digestsize(crypto_ahash_reqtfm(req)));
-
- kzfree(priv);
}
-static void ahash_op_unaligned_done(struct crypto_async_request *req, int err)
+static void ahash_op_unaligned_done(struct crypto_async_request *areq, int err)
{
- struct ahash_request *areq = req->data;
- struct ahash_request_priv *priv = areq->priv;
- crypto_completion_t complete = priv->complete;
- void *data = priv->data;
+ struct ahash_request *req = areq->data;
+ struct ahash_request_priv *priv = req->priv;
+ struct crypto_async_request *data;
+
+ /*
+ * Restore the original request, see ahash_op_unaligned() for what
+ * goes where.
+ *
+ * The "struct ahash_request *req" here is in fact the "req.base"
+ * from the ADJUSTED request from ahash_op_unaligned(), thus as it
+ * is a pointer to self, it is also the ADJUSTED "req" .
+ */
+
+ /* First copy req->result into req->priv.result */
+ ahash_op_unaligned_finish(req, err);
- ahash_op_unaligned_finish(areq, err);
+ /* Restore the original crypto request. */
+ req->result = priv->result;
+ req->base.complete = priv->complete;
+ req->base.data = priv->data;
+ req->priv = priv->priv;
- areq->base.complete = complete;
- areq->base.data = data;
+ /* Free the req->priv.priv from the ADJUSTED request. */
+ kzfree(priv);
- complete(&areq->base, err);
+ /* Complete the ORIGINAL request. */
+ data = req->base.data;
+ req->base.complete(data, err);
}
static int ahash_op_unaligned(struct ahash_request *req,
@@ -234,9 +250,36 @@ static int ahash_op_unaligned(struct ahash_request *req,
if (!priv)
return -ENOMEM;
+ /*
+ * WARNING: Voodoo programming below!
+ *
+ * The code below is obscure and hard to understand, thus explanation
+ * is necessary. See include/crypto/hash.h and include/linux/crypto.h
+ * to understand the layout of structures used here!
+ *
+ * The code here will replace portions of the ORIGINAL request with
+ * pointers to new code and buffers so the hashing operation can store
+ * the result in aligned buffer. We will call the modified request
+ * an ADJUSTED request.
+ *
+ * The newly mangled request will look as such:
+ *
+ * req {
+ * .result = ADJUSTED[new aligned buffer]
+ * .base.complete = ADJUSTED[pointer to completion function]
+ * .base.data = ADJUSTED[*req (pointer to self)]
+ * .priv = ADJUSTED[new priv] {
+ * .result = ORIGINAL(result)
+ * .complete = ORIGINAL(base.complete)
+ * .data = ORIGINAL(base.data)
+ * .priv = ORIGINAL(priv)
+ * }
+ */
+
priv->result = req->result;
priv->complete = req->base.complete;
priv->data = req->base.data;
+ priv->priv = req->priv;
req->result = PTR_ALIGN((u8 *)priv->ubuf, alignmask + 1);
req->base.complete = ahash_op_unaligned_done;
--
1.8.5.2
^ permalink raw reply related
* [PATCH 0/3] crypto: Clean up ahash handling confusion
From: Marek Vasut @ 2014-01-14 17:33 UTC (permalink / raw)
To: linux-arm-kernel
This set of patches shall clean up the confusion in restoring the ahash request
context in crypto/ahash.c . The code was a bit refactored to make it easier to
understand as well.
Please, make sure the code is well tested before applying. Also, please review
very thoroughly.
Marek Vasut (3):
crypto: Fix the pointer voodoo in unaligned ahash
crypto: Pull out the functions to save/restore request
crypto: Simplify the ahash_finup implementation
crypto/ahash.c | 172 ++++++++++++++++++++++++++++++++++++---------------------
1 file changed, 110 insertions(+), 62 deletions(-)
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
--
1.8.5.2
^ permalink raw reply
* [PATCH] dcp: aes: Move the AES operation type from actx to rctx
From: Marek Vasut @ 2014-01-14 17:31 UTC (permalink / raw)
To: linux-arm-kernel
Move the AES operation type and mode from async crypto context to
crypto request context. This allows for recycling of the async crypto
context for different kinds of operations.
I found this problem when I used dm-crypt, which uses the same async
crypto context (actx) for both encryption and decryption requests.
Since the requests are enqueued into the processing queue, immediatelly
storing the type of operation into async crypto context (actx) caused
corruption of this information when encryption and decryption operations
followed imediatelly one after the other. When the first operation was
dequeued, the second operation was already enqueued and overwritten the
type of operation in actx, thus causing incorrect result of the first
operation.
Fix this problem by storing the type of operation into the crypto request
context.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
---
drivers/crypto/mxs-dcp.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index d41917c..48f12dd 100644
--- a/drivers/crypto/mxs-dcp.c
+++ b/drivers/crypto/mxs-dcp.c
@@ -83,13 +83,16 @@ struct dcp_async_ctx {
unsigned int hot:1;
/* Crypto-specific context */
- unsigned int enc:1;
- unsigned int ecb:1;
struct crypto_ablkcipher *fallback;
unsigned int key_len;
uint8_t key[AES_KEYSIZE_128];
};
+struct dcp_aes_req_ctx {
+ unsigned int enc:1;
+ unsigned int ecb:1;
+};
+
struct dcp_sha_req_ctx {
unsigned int init:1;
unsigned int fini:1;
@@ -190,10 +193,12 @@ static int mxs_dcp_start_dma(struct dcp_async_ctx *actx)
/*
* Encryption (AES128)
*/
-static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, int init)
+static int mxs_dcp_run_aes(struct dcp_async_ctx *actx,
+ struct ablkcipher_request *req, int init)
{
struct dcp *sdcp = global_sdcp;
struct dcp_dma_desc *desc = &sdcp->coh->desc[actx->chan];
+ struct dcp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
int ret;
dma_addr_t key_phys = dma_map_single(sdcp->dev, sdcp->coh->aes_key,
@@ -212,14 +217,14 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, int init)
/* Payload contains the key. */
desc->control0 |= MXS_DCP_CONTROL0_PAYLOAD_KEY;
- if (actx->enc)
+ if (rctx->enc)
desc->control0 |= MXS_DCP_CONTROL0_CIPHER_ENCRYPT;
if (init)
desc->control0 |= MXS_DCP_CONTROL0_CIPHER_INIT;
desc->control1 = MXS_DCP_CONTROL1_CIPHER_SELECT_AES128;
- if (actx->ecb)
+ if (rctx->ecb)
desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_ECB;
else
desc->control1 |= MXS_DCP_CONTROL1_CIPHER_MODE_CBC;
@@ -247,6 +252,7 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
struct ablkcipher_request *req = ablkcipher_request_cast(arq);
struct dcp_async_ctx *actx = crypto_tfm_ctx(arq->tfm);
+ struct dcp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
struct scatterlist *dst = req->dst;
struct scatterlist *src = req->src;
@@ -271,7 +277,7 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
/* Copy the key from the temporary location. */
memcpy(key, actx->key, actx->key_len);
- if (!actx->ecb) {
+ if (!rctx->ecb) {
/* Copy the CBC IV just past the key. */
memcpy(key + AES_KEYSIZE_128, req->info, AES_KEYSIZE_128);
/* CBC needs the INIT set. */
@@ -300,7 +306,7 @@ static int mxs_dcp_aes_block_crypt(struct crypto_async_request *arq)
* submit the buffer.
*/
if (actx->fill == out_off || sg_is_last(src)) {
- ret = mxs_dcp_run_aes(actx, init);
+ ret = mxs_dcp_run_aes(actx, req, init);
if (ret)
return ret;
init = 0;
@@ -391,13 +397,14 @@ static int mxs_dcp_aes_enqueue(struct ablkcipher_request *req, int enc, int ecb)
struct dcp *sdcp = global_sdcp;
struct crypto_async_request *arq = &req->base;
struct dcp_async_ctx *actx = crypto_tfm_ctx(arq->tfm);
+ struct dcp_aes_req_ctx *rctx = ablkcipher_request_ctx(req);
int ret;
if (unlikely(actx->key_len != AES_KEYSIZE_128))
return mxs_dcp_block_fallback(req, enc);
- actx->enc = enc;
- actx->ecb = ecb;
+ rctx->enc = enc;
+ rctx->ecb = ecb;
actx->chan = DCP_CHAN_CRYPTO;
mutex_lock(&sdcp->mutex[actx->chan]);
@@ -484,7 +491,7 @@ static int mxs_dcp_aes_fallback_init(struct crypto_tfm *tfm)
return PTR_ERR(blk);
actx->fallback = blk;
- tfm->crt_ablkcipher.reqsize = sizeof(struct dcp_async_ctx);
+ tfm->crt_ablkcipher.reqsize = sizeof(struct dcp_aes_req_ctx);
return 0;
}
--
1.8.5.2
^ permalink raw reply related
* [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
From: Felipe Balbi @ 2014-01-14 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D56B13.2050409@ti.com>
On Tue, Jan 14, 2014 at 10:51:31AM -0600, Anna, Suman wrote:
> Felipe,
>
> On 01/14/2014 07:12 AM, Felipe Balbi wrote:
> >On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote:
> >>HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
> >>device families as well. The IPs are identical to that of
> >>OMAP4/OMAP5, except for the number of locks.
> >>
> >>Add a depends on to the above family of SoCs to enable the
> >>build support for OMAP hwspinlock driver for any of the above
> >>SoC configs.
> >>
> >>Signed-off-by: Suman Anna <s-anna@ti.com>
> >>---
> >> drivers/hwspinlock/Kconfig | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
> >>index 70637d2..3612cb5 100644
> >>--- a/drivers/hwspinlock/Kconfig
> >>+++ b/drivers/hwspinlock/Kconfig
> >>@@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
> >>
> >> config HWSPINLOCK_OMAP
> >> tristate "OMAP Hardware Spinlock device"
> >>- depends on ARCH_OMAP4 || SOC_OMAP5
> >>+ depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX
> >
> >how about just using ARCH_OMAP2PLUS ?
>
> We do not want the driver to build in OMAP2-only and/or OMAP3-only
> configurations, on which the hwspinlock IP is not even present.
It won't be enabled by default, will it ? You're just saying that it
_can_ be enabled. In fact, I would go one step further and use:
depends on ARCH_OMAP2PLUS || COMPILE_TEST
your choice though ;-)
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140114/05d03c96/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] mmc: dw_mmc: use slot-gpio to handle cd pin
From: Olof Johansson @ 2014-01-14 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGa+x85awFYsrU9Gggirpaip3vggtSqu5GinVzss=nfNcp4nww@mail.gmail.com>
On Tue, Jan 14, 2014 at 7:58 AM, Kevin Hilman <khilman@linaro.org> wrote:
> On Thu, Jan 9, 2014 at 6:35 AM, Zhangfei Gao <zhangfei.gao@linaro.org> wrote:
>> Suggested by Jaehoon: Use slot-gpio to handle cd-gpio
>> Add function dw_mci_of_get_cd_gpio to check "cd-gpios" from dts.
>> mmc_gpio_request_cd and mmc_gpio_get_cd are used to handle cd pin
>>
>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
>
> The Samsung Arndale board started failing boot from MMC root tests
> starting with next-20140113 and I bisected it down to this patch.
> Reverting this patch on top of next-20140114 gets Arndale booting
> again from MMC. Is there some supporting DT data that's missing for
> Arndale?
Rather, it looks like this patch changes behaviour and no longer uses
dw_mci_get_cd() to find out if there's a card attached -- it switches
to rely only on GPIO (see the last chunk in the patch). That seems
broken?
-Olof
^ permalink raw reply
* AArch64 kernel image decompression
From: Olof Johansson @ 2014-01-14 17:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114134732.F0A1C3821F2@gemini.denx.de>
On Tue, Jan 14, 2014 at 5:47 AM, Wolfgang Denk <wd@denx.de> wrote:
> Dear Bhupesh,
>
> In message <819346bb83b04348a266643afd5bd6f6@BN1PR03MB220.namprd03.prod.outlook.com> you wrote:
>>
>> I agree with Marek. Usually for non-cryptographic-secure (key based cryptography) boot
>> method the CRC protection is usually the best possible protection against Image
>> corruption. CRC check is usually used in a number of field-deployed solutions to ensure
>> linux image sanity.
>
> The FIT image approach as suggested by Marek also allows for secure
> boot methods (like cryptographically signed images); this is used in
> production for several systems, including the Google Chromebook.
This can very easily be misunderstood so I would like to clarify:
Chromebooks do not use the fitImage version of signatures and
verification, it is done independently from a separate library that
wraps either a zImage (x86) or a fitImage (ARM).
-Olof
^ permalink raw reply
* [PATCH v6 5/6] ACPI: do not map/unmap memory regions for FADT entries in reduced HW mode
From: Al Stone @ 2014-01-14 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D48BED.4060505@linaro.org>
On 01/13/2014 05:59 PM, Al Stone wrote:
> On 01/13/2014 05:02 PM, Rafael J. Wysocki wrote:
>> On Monday, January 13, 2014 04:07:19 PM Al Stone wrote:
>>> On 01/10/2014 04:32 PM, Rafael J. Wysocki wrote:
>>>> On Friday, January 10, 2014 03:52:19 PM al.stone at linaro.org wrote:
>>>>> From: Al Stone <al.stone@linaro.org>
>>>>>
>>>>> Several of the FADT fields are normally kept in specific memory
>>>>> regions. Since these fields are to be ignored in hardware reduced
>>>>> ACPI mode, do not map those addresses when in that mode, and of
>>>>> course do not release the mappings that have not been made.
>>>>>
>>>>> The function acpi_os_initialize() could become a stub in the header
>>>>> file but is left here in case it can be of further use.
>>>>
>>>> Why exactly is this change necessary?
>>>
>>> Two reasons: (1) why do work we do not have to do? and (2) it
>>> seemed to make sense to me to have the code reflect the spec
>>> accurately.
>>>
>>>> Will things work incorrectly on HW-reduced ACPI systems if we don't
>>>> make it?
>>>
>>> If the ACPI tables have all of these fields properly set to zero
>>> in hardware reduced, this change does not need to be made. If a
>>> vendor provides broken ACPI tables where these values are valid,
>>> but still sets hardware reduced in the FADT, these fields could
>>> then be used as before -- but allowing them to be used would mean
>>> we can no longer claim we are implementing hardware reduced correctly.
>>> So things would work, but the system would by definition be in some
>>> sort of undefined hybrid ACPI mode.
>>
>> So this is how it goes. I'm being told that there are systems in
>> existence
>> where the HW-reduced bit is set for Windows RT compatibility, but
>> otherwise
>> the ACPI HW is fully functional on them. Apparently, people are able to
>> install and run Linux on those systems today.
>>
>> Question is, are they still going to be able to run Linux on them
>> after the
>> changes in this set?
>
> Hrm. This would have been incredibly useful to know earlier. I
> might have taken a completely different approach. Or perhaps not
> even have bothered.
>
> I'm not naive enough to think all vendors will fully or rigorously
> comply with standards. Down that path madness lies. But at face
> value, it sounds like they didn't even try.
>
> Without access to the ACPI tables and the hardware itself, there is
> no way to know if Linux will run; I have yet to see any such system.
> The phrase "...the ACPI HW is fully functional..." could mean way too
> many things -- it could mean anything from strict compliance with
> hardware reduced mode to completely compliant with legacy mode but all
> we did was toggle the hardware reduced flag so we could use GPIOs
> instead of an SCI.
>
> As far as I can tell, that makes the question undecidable. I can't
> prove a negative -- I can't prove these patches won't break an unknown
> set of systems that have implemented an unknown hybrid of legacy and
> hardware reduced modes.
>
> If someone can tell me that these mongrel ACPI systems continue
> to run correctly when they run a Linux built with the
> ACPI_REDUCED_HARDWARE flag set in the ACPICA code, I might at least
> have a clue as to where the boundaries of compliance are.
>
> Or, if such hardware is commercially available, where does one get it?
>
> Otherwise, the only safe patch is 1/6, the Kconfig changes.
>
Thinking about this over night, I'll re-submit just the Kconfig changes
for now, and rethink the approach.
In the meantime... seriously, what devices are these with the weird
ACPI tables and hardware? How do I get one? Or access to one? A part
number or a vendor or something is kind of essential here; otherwise, I
can only surmise they are being done behind closed doors somewhere.
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------
^ permalink raw reply
* [PATCH v2 03/12] at91: dt: sam9261: Added support for the lcd display
From: Nicolas Ferre @ 2014-01-14 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389270709-32662-4-git-send-email-jjhiblot@traphandler.com>
On 09/01/2014 13:31, Jean-Jacques Hiblot :
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/boot/dts/at91sam9261.dtsi | 37 ++++++++++++++++++++++++++++++++++++-
> arch/arm/boot/dts/at91sam9261ek.dts | 31 +++++++++++++++++++++++++++++++
> arch/arm/mach-at91/at91sam9261.c | 1 +
> 3 files changed, 68 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi
> index 773c3d6..cd219b9 100644
> --- a/arch/arm/boot/dts/at91sam9261.dtsi
> +++ b/arch/arm/boot/dts/at91sam9261.dtsi
> @@ -290,7 +290,33 @@
> atmel,pins = <AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> };
> };
> -
> + fb {
> + pinctrl_fb: fb-0 {
> + atmel,pins =
> + <AT91_PIOB 1 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB1 periph A */
Ditto: remove comments.
> + AT91_PIOB 2 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB2 periph A */
> + AT91_PIOB 3 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB3 periph A */
> + AT91_PIOB 7 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB7 periph A */
> + AT91_PIOB 8 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB8 periph A */
> + AT91_PIOB 9 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB9 periph A */
> + AT91_PIOB 10 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB10 periph A */
> + AT91_PIOB 11 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB11 periph A */
> + AT91_PIOB 12 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB12 periph A */
> + AT91_PIOB 15 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB15 periph A */
> + AT91_PIOB 16 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB16 periph A */
> + AT91_PIOB 17 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB17 periph A */
> + AT91_PIOB 18 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB18 periph A */
> + AT91_PIOB 19 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB19 periph A */
> + AT91_PIOB 20 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB20 periph A */
> + AT91_PIOB 23 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB23 periph B */
> + AT91_PIOB 24 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB24 periph B */
> + AT91_PIOB 25 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB25 periph B */
> + AT91_PIOB 26 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB26 periph B */
> + AT91_PIOB 27 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB27 periph B */
> + AT91_PIOB 28 AT91_PERIPH_B AT91_PINCTRL_NONE /* PB28 periph B */
> + >;
> + };
> + };
> pioA: gpio at fffff400 {
> compatible = "atmel,at91rm9200-gpio";
> reg = <0xfffff400 0x200>;
> @@ -436,6 +462,15 @@
> };
> };
>
> + fb0: fb at 0x00600000 {
> + compatible = "atmel,at91sam9261-lcdc";
> + reg = <0x00600000 0x1000>;
> + interrupts = <21 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_fb>;
> + status = "disabled";
> + };
> +
> nand0: nand at 40000000 {
> compatible = "atmel,at91rm9200-nand";
> #address-cells = <1>;
> diff --git a/arch/arm/boot/dts/at91sam9261ek.dts b/arch/arm/boot/dts/at91sam9261ek.dts
> index f3d22a9..03c05fc 100644
> --- a/arch/arm/boot/dts/at91sam9261ek.dts
> +++ b/arch/arm/boot/dts/at91sam9261ek.dts
> @@ -52,6 +52,37 @@
> reg = <0x0 0x20000>;
> };
> };
> +
> + fb0: fb at 0x00600000 {
> + display = <&display0>;
> + status = "okay";
Nitpicking: Status is usually the last entry of a node (just before
sub-nodes): it is good to follow this habit.
> + atmel,power-control-gpio = <&pioA 12 GPIO_ACTIVE_LOW>;
> + display0: display {
> + bits-per-pixel = <16>;
> + atmel,lcdcon-backlight;
> + atmel,dmacon = <0x1>;
> + atmel,lcdcon2 = <0x80008002>;
> + atmel,guard-time = <1>;
> + atmel,lcd-wiring-mode = "BRG";
> +
> + display-timings {
> + native-mode = <&timing0>;
> + timing0: timing0 {
> + clock-frequency = <4965000>;
> + hactive = <240>;
> + vactive = <320>;
> + hback-porch = <1>;
> + hfront-porch = <33>;
> + vback-porch = <1>;
> + vfront-porch = <0>;
> + hsync-len = <5>;
> + vsync-len = <1>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + };
> + };
> + };
> + };
> };
>
> leds {
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 200d17a..a67bfe6 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -197,6 +197,7 @@ static struct clk_lookup periph_clocks_lookups[] = {
> /* more tc lookup table for DT entries */
> CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
> CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
> + CLKDEV_CON_DEV_ID("hclk", "600000.fb", &hck1),
> CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
> CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
> CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
>
--
Nicolas Ferre
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Sarah Sharp @ 2014-01-14 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87sissopaf.fsf@natisbad.org>
On Sun, Jan 12, 2014 at 10:36:56PM +0100, Arnaud Ebalard wrote:
> Hi,
>
> arno at natisbad.org (Arnaud Ebalard) writes:
>
> > Both with a LaCie 2.5" USB 3.0 Rugged Mini disk (powered by the port)
> > and a 3.5" SATA disk connected via an ICY DOCK MB981U3S-1S dock station
> > (external power), I can transfer huge files w/o issue but I get the
> > following when transferring small files (e.g. copy of some debian
> > directory to a folder on the disk):
> >
> > # cp -rf /lib/ /bin/ /sbin/ /opt /var/ /usr/ test/
> > [ 327.130045] xhci_hcd 0000:02:00.0: xHCI host not responding to stop endpoint command.
> > [ 327.137899] xhci_hcd 0000:02:00.0: Assuming host is dying, halting host.
> > [ 327.144644] xhci_hcd 0000:02:00.0: HC died; cleaning up
Hmm, you're the second person to report an issue with a host dying.
> I can add the following:
>
> 2) I just tested the copy of the small files using the ICY DOCK
> MB981U3S-1S connected to my ReadyNAS 102 *on a 3.11.7 kernel*
> and it completed successfully.
Please try a 3.13-rc7 kernel after running `git revert 35773dac5f86`.
> 2) on current 3.13.0-rc7 kernel (w/ Bj?rn patch applied just in case), I
Which patch are you referring to?
> just transferred 40GB through a Logitec LAN-GT JU3H3 (it is based on an
> ASIX AX88179) connected to my ReadyNAS Duo v2 (NEC XHCI controller) at
> an average rate of 82MB/s. Bottom line: no issue. When I try to do the
> same on my ReadyNAS 102, I immediately get complaints:
Was the ReadyNAS 102 with the Fresco Logic host running 3.13.0-rc7 as
well?
> [ 383.280429] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 383.280892] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 411.620073] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20352 bytes untransferred
> [ 411.620750] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 411.621727] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.066651] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20352 bytes untransferred
> [ 412.067233] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.068196] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.242708] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20352 bytes untransferred
> [ 412.243333] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.244246] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.417956] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20352 bytes untransferred
> [ 412.418516] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.419473] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20400 bytes untransferred
> [ 412.545330] xhci_hcd 0000:02:00.0: ep 0x82 - asked for 20480 bytes, 20352 bytes untransferred
Those messages are normal. It just means the device transferred less
data than the host asked for, which is part of normal USB operation.
Does the dock work despite the messages?
Please send me the output of `sudo lspci -vvv -n` for the ReadyNAS 102
Fresco Logic host.
Sarah Sharp
^ permalink raw reply
* [PATCH v2 02/12] at91: dt: sam9261: Basic Device Tree support for the at91sam9261ek
From: Nicolas Ferre @ 2014-01-14 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389270709-32662-3-git-send-email-jjhiblot@traphandler.com>
On 09/01/2014 13:31, Jean-Jacques Hiblot :
> This patch implements a simple DTS to boot a at91sam9261ek with a dt-enabled
> kernel (at91_dt_defconfig).
> Only dbgu, nand and watchdog are described in the DT.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/at91sam9261ek.dts | 75 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 77 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 772a30e..ece523d 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -11,6 +11,8 @@ dtb-$(CONFIG_ARCH_AT91) += ethernut5.dtb
> dtb-$(CONFIG_ARCH_AT91) += evk-pro3.dtb
> dtb-$(CONFIG_ARCH_AT91) += tny_a9260.dtb
> dtb-$(CONFIG_ARCH_AT91) += usb_a9260.dtb
> +# sam9261
> +dtb-$(CONFIG_ARCH_AT91) += at91sam9261ek.dtb
> # sam9263
> dtb-$(CONFIG_ARCH_AT91) += at91sam9263ek.dtb
> dtb-$(CONFIG_ARCH_AT91) += tny_a9263.dtb
> diff --git a/arch/arm/boot/dts/at91sam9261ek.dts b/arch/arm/boot/dts/at91sam9261ek.dts
> new file mode 100644
> index 0000000..f3d22a9
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91sam9261ek.dts
> @@ -0,0 +1,75 @@
> +/*
> + * at91sam9261ek.dts - Device Tree file for Atmel at91sam9261 reference board
> + *
> + * Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> + *
> + * Licensed under GPLv2 only.
> + */
> +/dts-v1/;
> +#include "at91sam9261.dtsi"
> +
> +/ {
> + model = "Atmel at91sam9261ek";
> + compatible = "atmel,at91sam9261ek", "atmel,at91sam9261", "atmel,at91sam9";
> +
> + chosen {
> + bootargs = "mem=64M console=ttyS0,115200";
No "mem=" argument, please.
> + };
> +
> + memory {
> + reg = <0x20000000 0x4000000>;
This is where memory is specified.
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + main_clock: clock at 0 {
> + compatible = "atmel,osc", "fixed-clock";
> + clock-frequency = <18432000>;
> + };
> + };
> +
> + ahb {
> + apb {
> + dbgu: serial at fffff200 {
> + status = "okay";
> + };
> +
> + watchdog at fffffd40 {
> + status = "okay";
> + };
> + };
> +
> + nand0: nand at 40000000 {
> + nand-bus-width = <8>;
> + nand-ecc-mode = "soft";
> + nand-on-flash-bbt = <1>;
> + status = "okay";
> + at91bootstrap at 0 {
> + label = "at91bootstrap";
> + reg = <0x0 0x20000>;
Maybe more partitions are needed by default. You may need to align to
the common partition scheme the we use for sama5d3 and:
http://www.at91.com/linux4sam/bin/view/Linux4SAM/GettingStarted#Linux4SAM_NandFlash_demo_Memory
(even if it can be discussed ;-))
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + ds8 {
> + label = "ds8";
> + gpios = <&pioA 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "none";
> + };
> + ds7 {
> + label = "ds7";
> + gpios = <&pioA 14 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "nand-disk";
> + };
> + ds1 {
> + label = "ds1";
> + gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "heartbeat";
> + };
> + };
> +};
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH RFC 08/26] dmaengine: omap-dma: consolidate setup of CCR
From: Tony Lindgren @ 2014-01-14 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114133949.GJ27282@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [140114 05:41]:
> On Mon, Jan 13, 2014 at 11:12:27PM +0000, Russell King - ARM Linux wrote:
> > On Mon, Jan 13, 2014 at 02:14:26PM -0800, Tony Lindgren wrote:
> > > * Russell King <rmk+kernel@arm.linux.org.uk> [140102 07:17]:
> > > > Consolidate the setup of the channel control register. Prepare the
> > > > basic value in the preparation of the DMA descriptor, and write it into
> > > > the register upon descriptor execution.
> > >
> > > FYI, this patch seems to be the one that causes the
> > > "DMA timeout with device 55" error for omap1.
> >
> > Okay, looks like I've missed some bit of muxing for DMA signals or
> > something. I've yet to find any information on this in the OMAP5912
> > docs, so I guess I'm going to have to do this not only blind, but also
> > without hardware. GAH.
>
> Do you know which of the OMAP1 variants your device is? Is it OMAP15xx
> or OMAP16xx? It looks like OMAP15xx is easy to fix for this as it hasn't
> got the additional multiplexer on the DMA request signals.
This was with Nokia 770, which is 1710. Should be pretty much the same
from SoC point of view as 5912 on OSK.
Tony
^ permalink raw reply
* [PATCH v2 01/12] at91: dt: Add at91sam9261 dt SoC support
From: Nicolas Ferre @ 2014-01-14 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389270709-32662-2-git-send-email-jjhiblot@traphandler.com>
On 09/01/2014 13:31, Jean-Jacques Hiblot :
> This patch adds the basics to support the Device Tree on a sam9261-based platform
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/boot/dts/at91sam9261.dtsi | 476 +++++++++++++++++++++++++++++++++++++
> arch/arm/mach-at91/at91sam9261.c | 15 ++
> 2 files changed, 491 insertions(+)
> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
>
> diff --git a/arch/arm/boot/dts/at91sam9261.dtsi b/arch/arm/boot/dts/at91sam9261.dtsi
> new file mode 100644
> index 0000000..773c3d6
> --- /dev/null
> +++ b/arch/arm/boot/dts/at91sam9261.dtsi
> @@ -0,0 +1,476 @@
> +/*
> + * at91sam9261.dtsi - Device Tree Include file for AT91SAM9261 SoC
> + *
> + * Copyright (C) 2013 Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> + *
> + * Licensed under GPLv2 only.
> + */
> +
> +#include "skeleton.dtsi"
> +#include <dt-bindings/pinctrl/at91.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include <dt-bindings/gpio/gpio.h>
> +
> +/ {
> + model = "Atmel AT91SAM9261 family SoC";
> + compatible = "atmel,at91sam9261";
> + interrupt-parent = <&aic>;
> +
> + aliases {
> + serial0 = &dbgu;
> + serial1 = &usart0;
> + serial2 = &usart1;
> + serial3 = &usart2;
> + gpio0 = &pioA;
> + gpio1 = &pioB;
> + gpio2 = &pioC;
> + tcb0 = &tcb0;
> + i2c0 = &i2c0;
> + ssc0 = &ssc0;
> + ssc1 = &ssc1;
> + };
> + cpus {
> + #address-cells = <0>;
> + #size-cells = <0>;
> +
> + cpu {
> + compatible = "arm,arm926ej-s";
> + device_type = "cpu";
> + };
> + };
> +
> + memory {
> + reg = <0x20000000 0x08000000>;
> + };
> +
> + ahb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + apb {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
I know that it is not always done but can you please sort all nodes by
ascending address order? It is always simple to deal with node additions
when sorted this way.
> +
> + aic: interrupt-controller at fffff000 {
> + #interrupt-cells = <3>;
> + compatible = "atmel,at91rm9200-aic";
> + interrupt-controller;
> + reg = <0xfffff000 0x200>;
> + atmel,external-irqs = <29 30 31>;
> + };
> +
> + pmc: pmc at fffffc00 {
> + compatible = "atmel,at91rm9200-pmc";
> + reg = <0xfffffc00 0x100>;
> + };
> +
> + ramc: ramc at ffffea00 {
> + compatible = "atmel,at91sam9260-sdramc";
> + reg = <0xffffea00 0x200>;
> + };
> +
> + pit: timer at fffffd30 {
> + compatible = "atmel,at91sam9260-pit";
> + reg = <0xfffffd30 0xf>;
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
> + };
> +
> + tcb0: timer at fffa0000 {
> + compatible = "atmel,at91rm9200-tcb";
> + reg = <0xfffa0000 0x100>;
> + interrupts = < 17 IRQ_TYPE_LEVEL_HIGH 0
> + 18 IRQ_TYPE_LEVEL_HIGH 0
> + 19 IRQ_TYPE_LEVEL_HIGH 0
> + >;
> + status = "disabled";
> + };
> +
> + rstc at fffffd00 {
> + compatible = "atmel,at91sam9260-rstc";
> + reg = <0xfffffd00 0x10>;
> + };
> +
> + shdwc at fffffd10 {
> + compatible = "atmel,at91sam9260-shdwc";
> + reg = <0xfffffd10 0x10>;
> + };
> +
> + pinctrl at fffff400 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "atmel,at91rm9200-pinctrl", "simple-bus";
> + ranges = <0xfffff400 0xfffff400 0xa00>;
> +
> + atmel,mux-mask = <
> + /* A B */
> + 0xffffffff 0xfffffff7 /* pioA */
> + 0xffffffff 0xfffffff4 /* pioB */
> + 0xffffffff 0xffffff07 /* pioC */
> + >;
> +
> + /* shared pinctrl settings */
> + dbgu {
> + pinctrl_dbgu: dbgu-0 {
> + atmel,pins =
> + <AT91_PIOA 9 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA9 periph A */
You may have to remove comments for pin descriptions. It is not needed
anymore with pre-processor macros.
> + AT91_PIOA 10 AT91_PERIPH_A AT91_PINCTRL_PULL_UP>; /* PA10 periph A with pullup */
> + };
> + };
> +
> + usart0 {
> + pinctrl_usart0: usart0-0 {
> + atmel,pins =
> + <AT91_PIOC 8 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC8 periph A with pullup */
> + AT91_PIOC 9 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC9 periph A */
> + };
> +
> + pinctrl_usart0_rts: usart0_rts-0 {
> + atmel,pins =
> + <AT91_PIOC 10 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC10 periph A */
> + };
> +
> + pinctrl_usart0_cts: usart0_cts-0 {
> + atmel,pins =
> + <AT91_PIOC 11 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC11 periph A */
> + };
> + };
> +
> + usart1 {
> + pinctrl_usart1: usart1-0 {
> + atmel,pins =
> + <AT91_PIOC 12 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC12 periph A with pullup */
> + AT91_PIOC 13 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC13 periph A */
> + };
> +
> + pinctrl_usart1_rts: usart1_rts-0 {
> + atmel,pins =
> + <AT91_PIOA 12 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA12 periph B */
> + };
> +
> + pinctrl_usart1_cts: usart1_cts-0 {
> + atmel,pins =
> + <AT91_PIOA 13 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA13 periph B */
> + };
> + };
> +
> + usart2 {
> + pinctrl_usart2: usart2-0 {
> + atmel,pins =
> + <AT91_PIOC 14 AT91_PERIPH_A AT91_PINCTRL_PULL_UP /* PC14 periph A with pullup */
> + AT91_PIOC 15 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PC15 periph A */
> + };
> +
> + pinctrl_usart2_rts: usart2_rts-0 {
> + atmel,pins =
> + <AT91_PIOA 15 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA15 periph B */
> + };
> +
> + pinctrl_usart2_cts: usart2_cts-0 {
> + atmel,pins =
> + <AT91_PIOA 16 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA16 periph B */
> + };
> + };
> +
> + nand {
> + pinctrl_nand: nand-0 {
> + atmel,pins =
> + <AT91_PIOC 15 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP /* PC15 gpio RDY pin pull_up*/
> + AT91_PIOC 14 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>; /* PC14 gpio enable pin pull_up */
> + };
> + };
> +
> + mmc0 {
> + pinctrl_mmc0_clk: mmc0_clk-0 {
> + atmel,pins =
> + <AT91_PIOA 2 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA2 periph B */
> + };
> +
> + pinctrl_mmc0_slot0_cmd_dat0: mmc0_slot0_cmd_dat0-0 {
> + atmel,pins =
> + <AT91_PIOA 1 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA1 periph B with pullup */
> + AT91_PIOA 0 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA0 periph B with pullup */
> + };
> +
> + pinctrl_mmc0_slot0_dat1_3: mmc0_slot0_dat1_3-0 {
> + atmel,pins =
> + <AT91_PIOA 4 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA4 periph B with pullup */
> + AT91_PIOA 5 AT91_PERIPH_B AT91_PINCTRL_PULL_UP /* PA5 periph B with pullup */
> + AT91_PIOA 6 AT91_PERIPH_B AT91_PINCTRL_PULL_UP>; /* PA6 periph B with pullup */
> + };
> + };
> +
> + ssc0 {
> + pinctrl_ssc0_tx: ssc0_tx-0 {
> + atmel,pins =
> + <AT91_PIOB 21 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB21 periph A */
> + AT91_PIOB 22 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB22 periph A */
> + AT91_PIOB 23 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB23 periph A */
> + };
> +
> + pinctrl_ssc0_rx: ssc0_rx-0 {
> + atmel,pins =
> + <AT91_PIOB 24 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB24 periph A */
> + AT91_PIOB 25 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB25 periph A */
> + AT91_PIOB 26 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB26 periph A */
> + };
> + };
> +
> + ssc1 {
> + pinctrl_ssc1_tx: ssc1_tx-0 {
> + atmel,pins =
> + <AT91_PIOA 17 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA17 periph B */
> + AT91_PIOA 18 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA18 periph B */
> + AT91_PIOA 19 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA19 periph B */
> + };
> +
> + pinctrl_ssc1_rx: ssc1_rx-0 {
> + atmel,pins =
> + <AT91_PIOA 20 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA20 periph B */
> + AT91_PIOA 21 AT91_PERIPH_B AT91_PINCTRL_NONE /* PA21 periph B */
> + AT91_PIOA 22 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PA22 periph B */
> + };
> + };
> +
> + spi0 {
> + pinctrl_spi0: spi0-0 {
> + atmel,pins =
> + <AT91_PIOA 0 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA0 periph A SPI0_MISO pin */
> + AT91_PIOA 1 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA1 periph A SPI0_MOSI pin */
> + AT91_PIOA 2 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA2 periph A SPI0_SPCK pin */
> + };
> + };
> +
> + spi1 {
> + pinctrl_spi1: spi1-0 {
> + atmel,pins =
> + <AT91_PIOB 30 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB30 periph A SPI1_MISO pin */
> + AT91_PIOB 31 AT91_PERIPH_A AT91_PINCTRL_NONE /* PB31 periph A SPI1_MOSI pin */
> + AT91_PIOB 29 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PB29 periph A SPI1_SPCK pin */
> + };
> + };
> +
> + tcb0 {
> + pinctrl_tcb0_tclk0: tcb0_tclk0-0 {
> + atmel,pins = <AT91_PIOC 16 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tclk1: tcb0_tclk1-0 {
> + atmel,pins = <AT91_PIOC 17 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tclk2: tcb0_tclk2-0 {
> + atmel,pins = <AT91_PIOC 18 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tioa0: tcb0_tioa0-0 {
> + atmel,pins = <AT91_PIOC 19 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tioa1: tcb0_tioa1-0 {
> + atmel,pins = <AT91_PIOC 21 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tioa2: tcb0_tioa2-0 {
> + atmel,pins = <AT91_PIOC 23 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tiob0: tcb0_tiob0-0 {
> + atmel,pins = <AT91_PIOC 20 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tiob1: tcb0_tiob1-0 {
> + atmel,pins = <AT91_PIOC 22 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> +
> + pinctrl_tcb0_tiob2: tcb0_tiob2-0 {
> + atmel,pins = <AT91_PIOC 24 AT91_PERIPH_B AT91_PINCTRL_NONE>;
> + };
> + };
> +
> + pioA: gpio at fffff400 {
> + compatible = "atmel,at91rm9200-gpio";
> + reg = <0xfffff400 0x200>;
> + interrupts = <2 IRQ_TYPE_LEVEL_HIGH 1>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pioB: gpio at fffff600 {
> + compatible = "atmel,at91rm9200-gpio";
> + reg = <0xfffff600 0x200>;
> + interrupts = <3 IRQ_TYPE_LEVEL_HIGH 1>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + pioC: gpio at fffff800 {
> + compatible = "atmel,at91rm9200-gpio";
> + reg = <0xfffff800 0x200>;
> + interrupts = <4 IRQ_TYPE_LEVEL_HIGH 1>;
> + #gpio-cells = <2>;
> + gpio-controller;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> + dbgu: serial at fffff200 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffff200 0x200>;
> + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_dbgu>;
> + status = "disabled";
> + };
> +
> + usart0: serial at fffb0000 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb0000 0x200>;
> + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart0>;
> + status = "disabled";
> + };
> +
> + usart1: serial at ffffb400 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb4000 0x200>;
> + interrupts = <7 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart1>;
> + status = "disabled";
> + };
> +
> + usart2: serial at fff94000 {
> + compatible = "atmel,at91sam9260-usart";
> + reg = <0xfffb8000 0x200>;
> + interrupts = <8 IRQ_TYPE_LEVEL_HIGH 5>;
> + atmel,use-dma-rx;
> + atmel,use-dma-tx;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usart2>;
> + status = "disabled";
> + };
> +
> + ssc0: ssc at fffbc000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfffbc000 0x4000>;
> + interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
> + status = "disabled";
> + };
> +
> + ssc1: ssc at fffc0000 {
> + compatible = "atmel,at91rm9200-ssc";
> + reg = <0xfffc0000 0x4000>;
> + interrupts = <15 IRQ_TYPE_LEVEL_HIGH 5>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ssc1_tx &pinctrl_ssc1_rx>;
> + status = "disabled";
> + };
> +
> + usb1: gadget at fffa4000 {
> + compatible = "atmel,at91rm9200-udc";
> + reg = <0xfffa4000 0x4000>;
> + interrupts = <10 IRQ_TYPE_LEVEL_HIGH 2>;
> + status = "disabled";
> + };
> +
> + i2c0: i2c at fffac000 {
> + compatible = "atmel,at91sam9261-i2c";
isn't it "atmel,at91sam9260-i2c" ?
> + reg = <0xfffac000 0x100>;
> + interrupts = <11 IRQ_TYPE_LEVEL_HIGH 6>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + mmc0: mmc at fffa8000 {
> + compatible = "atmel,hsmci";
> + reg = <0xfffa8000 0x600>;
> + interrupts = <9 IRQ_TYPE_LEVEL_HIGH 0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> + watchdog at fffffd40 {
> + compatible = "atmel,at91sam9260-wdt";
> + reg = <0xfffffd40 0x10>;
> + status = "disabled";
> + };
> +
> + spi0: spi at fffc8000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0xfffc8000 0x200>;
> + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi0>;
> + status = "disabled";
> + };
> +
> + spi1: spi at fffcc000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0xfffcc000 0x200>;
> + interrupts = <13 IRQ_TYPE_LEVEL_HIGH 3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_spi1>;
> + status = "disabled";
> + };
> + };
> +
> + nand0: nand at 40000000 {
> + compatible = "atmel,at91rm9200-nand";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x40000000 0x10000000>;
> + atmel,nand-addr-offset = <22>;
> + atmel,nand-cmd-offset = <21>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_nand>;
> +
> + gpios = <&pioC 15 GPIO_ACTIVE_HIGH
> + &pioC 14 GPIO_ACTIVE_HIGH
> + 0
> + >;
> + status = "disabled";
> + };
> +
> + usb0: ohci at 00500000 {
> + compatible = "atmel,at91rm9200-ohci", "usb-ohci";
> + reg = <0x00500000 0x100000>;
> + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 2>;
> + status = "disabled";
> + };
> + };
> +
> + i2c at 0 {
> + compatible = "i2c-gpio";
> + gpios = <&pioA 7 GPIO_ACTIVE_HIGH /* sda */
> + &pioA 8 GPIO_ACTIVE_HIGH /* scl */
> + >;
> + i2c-gpio,sda-open-drain;
> + i2c-gpio,scl-open-drain;
> + i2c-gpio,delay-us = <2>; /* ~100 kHz */
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +};
> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c
> index 6276b4c..200d17a 100644
> --- a/arch/arm/mach-at91/at91sam9261.c
> +++ b/arch/arm/mach-at91/at91sam9261.c
> @@ -189,6 +189,21 @@ static struct clk_lookup periph_clocks_lookups[] = {
> CLKDEV_CON_ID("pioA", &pioA_clk),
> CLKDEV_CON_ID("pioB", &pioB_clk),
> CLKDEV_CON_ID("pioC", &pioC_clk),
> + /* more usart lookup table for DT entries */
> + CLKDEV_CON_DEV_ID("usart", "fffff200.serial", &mck),
> + CLKDEV_CON_DEV_ID("usart", "fffb0000.serial", &usart0_clk),
> + CLKDEV_CON_DEV_ID("usart", "ffffb400.serial", &usart1_clk),
> + CLKDEV_CON_DEV_ID("usart", "fff94000.serial", &usart2_clk),
> + /* more tc lookup table for DT entries */
> + CLKDEV_CON_DEV_ID("t0_clk", "fffa0000.timer", &tc0_clk),
> + CLKDEV_CON_DEV_ID("hclk", "500000.ohci", &ohci_clk),
> + CLKDEV_CON_DEV_ID("spi_clk", "fffc8000.spi", &spi0_clk),
> + CLKDEV_CON_DEV_ID("spi_clk", "fffcc000.spi", &spi1_clk),
> + CLKDEV_CON_DEV_ID("mci_clk", "fffa8000.mmc", &mmc_clk),
> + CLKDEV_CON_DEV_ID(NULL, "fffac000.i2c", &twi_clk),
> + CLKDEV_CON_DEV_ID(NULL, "fffff400.gpio", &pioA_clk),
> + CLKDEV_CON_DEV_ID(NULL, "fffff600.gpio", &pioB_clk),
> + CLKDEV_CON_DEV_ID(NULL, "fffff800.gpio", &pioC_clk),
Yes, this is where I would like the CCF to be implemented...
> };
>
> static struct clk_lookup usart_clocks_lookups[] = {
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCHv4 6/7] hwspinlock/omap: enable module before reading SYSSTATUS register
From: Anna, Suman @ 2014-01-14 16:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114140440.GA15785@saruman.home>
Felipe,
On 01/14/2014 08:04 AM, Felipe Balbi wrote:
> Hi again,
>
> On Tue, Jan 14, 2014 at 07:10:52AM -0600, Felipe Balbi wrote:
>>> diff --git a/drivers/hwspinlock/omap_hwspinlock.c b/drivers/hwspinlock/omap_hwspinlock.c
>>> index 9f56fb2..194886e 100644
>>> --- a/drivers/hwspinlock/omap_hwspinlock.c
>>> +++ b/drivers/hwspinlock/omap_hwspinlock.c
>>> @@ -101,10 +101,23 @@ static int omap_hwspinlock_probe(struct platform_device *pdev)
>>> if (!io_base)
>>> return -ENOMEM;
>>>
>>> + /*
>>> + * make sure the module is enabled and clocked before reading
>>> + * the module SYSSTATUS register
>>> + */
>>> + pm_runtime_enable(&pdev->dev);
>>> + pm_runtime_get_sync(&pdev->dev);
>
> another thing, you need to check return of pm_runtime_get_sync()
OK, let me check this and your other comment, and the fix is probably a
separate patch.
regards
Suman
^ permalink raw reply
* [PATCH v2 00/12] Device Tree support for the at91sam9261ek
From: Nicolas Ferre @ 2014-01-14 16:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389270709-32662-1-git-send-email-jjhiblot@traphandler.com>
On 09/01/2014 13:31, Jean-Jacques Hiblot :
> This patch set aims at bringing a basic device tree support for the sam9261.
> It's mostly based on the sam9263 stuff.
Nice! Thanks a lot for stepping up.
One general comment though: I would like to have new AT91 SoC described
in DT integrating mainline with Common Clock Framework implemented.
I feel that it would make sense to directly convert sam9261 to CCF to
avoid the pain of an intermediary DT description that would last only
for a couple of kernel revisions.
> It introduces a new driver for the smc/ebi bus. It's used to configure the EBI
> from the DT. I haven't documented its DT bindings yet. Timings can be provided
> as raw values or nanoseconds.
Thanks a lot for taking this SMC-as-a-driver task: it is very cool to
have it!
I will try to review your patches in the coming days... But Boris
already did a good job at this ;-)
> Change since V1:
> * changed the DT representation to use address translation and separate the
> timings' configuration from the device properties by adding a "simple-bus"
> inetrmediate node.
> * moved the smc driver from drivers/bus to drivers/memmory
> * smc driver now accepts timings in nanoseconds as well as raw register values
> * smc driver can clip the timings if they're out of bound and dump them to the
> console
> * DM9000 timings are now described in nanosecs (for the virtue of example)
>
> supported features:
> * dbgu
> * nand
> * lcd
> * ethernet
> * leds
>
> Jean-Jacques
>
> Jean-Jacques Hiblot (12):
> at91: dt: Add at91sam9261 dt SoC support
> at91: dt: sam9261: Basic Device Tree support for the at91sam9261ek
> at91: dt: sam9261: Added support for the lcd display
> at91: smc: export sam9_smc_cs_read and sam9_smc_cs_configure.
> at91: smc: Increased the size of tdf_cycles in struct sam9_smc_config.
> at91: smc: Adds helper functions to validate and clip the smc timings.
> at91: dt: smc: Added smc bus driver
> at91: sam9261: Add a clock definition for the smc
> at91: dt: sam9261: Pinmux DT entries for the SMC/EBI interface
> at91: dt: sam9261: Add an entry in the DT for the SMC/EBI bus driver.
> at91: dt: sam9261: moved the NAND under the smc node
> at91: dt: sam9261: Added DM9000 in the device tree
>
> arch/arm/boot/dts/Makefile | 2 +
> arch/arm/boot/dts/at91sam9261.dtsi | 639 +++++++++++++++++++++++++
> arch/arm/boot/dts/at91sam9261ek.dts | 164 +++++++
> arch/arm/mach-at91/at91sam9261.c | 17 +
> arch/arm/mach-at91/include/mach/at91sam9_smc.h | 6 +-
> arch/arm/mach-at91/sam9_smc.c | 81 +++-
> drivers/memory/Kconfig | 10 +
> drivers/memory/Makefile | 1 +
> drivers/memory/atmel-smc.c | 431 +++++++++++++++++
> 9 files changed, 1348 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/boot/dts/at91sam9261.dtsi
> create mode 100644 arch/arm/boot/dts/at91sam9261ek.dts
> create mode 100644 drivers/memory/atmel-smc.c
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCHv4 7/7] hwspinlock/omap: enable build for AM33xx, AM43xx & DRA7xx
From: Anna, Suman @ 2014-01-14 16:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114131207.GB10818@saruman.home>
Felipe,
On 01/14/2014 07:12 AM, Felipe Balbi wrote:
> On Mon, Jan 13, 2014 at 06:19:24PM -0600, Suman Anna wrote:
>> HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
>> device families as well. The IPs are identical to that of
>> OMAP4/OMAP5, except for the number of locks.
>>
>> Add a depends on to the above family of SoCs to enable the
>> build support for OMAP hwspinlock driver for any of the above
>> SoC configs.
>>
>> Signed-off-by: Suman Anna <s-anna@ti.com>
>> ---
>> drivers/hwspinlock/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
>> index 70637d2..3612cb5 100644
>> --- a/drivers/hwspinlock/Kconfig
>> +++ b/drivers/hwspinlock/Kconfig
>> @@ -10,7 +10,7 @@ menu "Hardware Spinlock drivers"
>>
>> config HWSPINLOCK_OMAP
>> tristate "OMAP Hardware Spinlock device"
>> - depends on ARCH_OMAP4 || SOC_OMAP5
>> + depends on ARCH_OMAP4 || SOC_OMAP5 || SOC_DRA7XX || SOC_AM33XX || SOC_AM43XX
>
> how about just using ARCH_OMAP2PLUS ?
We do not want the driver to build in OMAP2-only and/or OMAP3-only
configurations, on which the hwspinlock IP is not even present.
regards
Suman
^ permalink raw reply
* AArch64 kernel image decompression
From: Stephen Warren @ 2014-01-14 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401140714.52400.arnd@arndb.de>
On 01/13/2014 11:14 PM, Arnd Bergmann wrote:
...
> Note that uImage is fundamentally incompatible with multiplatform kernels,
> since it hardcodes the load address in the image file.
FWIW, with "mkimage -T kernel_noload", that's no longer true.
^ permalink raw reply
* [PATCH v8 3/4] ata: Add APM X-Gene SoC SATA host controller driver
From: Tejun Heo @ 2014-01-14 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPw-ZTn7QZkPGLMYkd0m4uS_vC53bOfv-N7M=jUTnzMSVJkMrw@mail.gmail.com>
On Tue, Jan 14, 2014 at 08:37:18AM -0800, Loc Ho wrote:
> This issue has NOT been observed but the design has this issue and
> observed from verification. As a mean to ensure that this never occur
> from design itself, this is the workaround and only apply to SATA and
> SDIO. The SDIO don't need this special flush as discussed in earlier
> email.
Urgh... can't say I'm a big fan of this hardware. :(
--
tejun
^ 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