* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 2)
From: Arnd Bergmann @ 2016-11-30 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-4-nsekhar@ti.com>
On Sunday, November 20, 2016 7:10:38 PM CET Sekhar Nori wrote:
> The following changes since commit 6e9be8608771192851a3adf59f0ba9240e3f802c:
>
> ARM: davinci_all_defconfig: enable LED default-on trigger (2016-11-01 11:42:54 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/defconfig-2
>
> for you to fetch changes up to a652baa06413a4beacc09425883e518c5f1ed100:
>
> ARM: davinci_all_defconfig: add missing options for systemd (2016-11-15 15:44:52 +0530)
>
> ----------------------------------------------------------------
> Enables newly introduced DDR controller and
> master priority setting drivers in kernel.
>
> Also, update defconfig to boot latest systemd
> based filesystems on DA850.
>
I pulled part 3 first, which contained this.
Arnd
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Dave Martin @ 2016-11-30 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com>
On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote:
> On 11/30/2016 01:06 PM, Dave Martin wrote:
>
> >I'm concerned here that there may be no sensible fixed size for the
> >signal frame. We would make it ridiculously large in order to minimise
> >the chance of hitting this problem again -- but then it would be
> >ridiculously large, which is a potential problem for massively threaded
> >workloads.
>
> What's ridiculously large?
The SVE architecture permits VLs up to 2048 bits per vector initially --
but it makes space for future architecture revisions to expand up to
65536 bits per vector, which would result in a signal frame > 270 KB.
It's far from certain we'll ever see such large vectors, but it's hard
to know where to draw the line.
> We could add a system call to get the right stack size. But as it depends
> on VL, I'm not sure what it looks like. Particularly if you need determine
> the stack size before creating a thread that uses a specific VL setting.
I think that the most likely time to set the VL is libc startup or ld.so
startup -- so really a process considers the VL fixed, and a
hypothetical getsigstksz() function would return a constant value
depending on the VL that was set.
I'd expect that only specialised code such as libc/ld.so itself or fancy
runtimes would need to cope with the need to synchronise stack
allocation with VL setting.
The initial stack after exec is determined by RLIMIT_STACK -- we can
expect that to be easily large enough for the initial thread, under any
remotely normal scenario.
> >For setcontext/setjmp, we don't save/restore any SVE state due to the
> >caller-save status of SVE, and I would not consider it necessary to
> >save/restore VL itself because of the no-change-on-the-fly policy for
> >this.
>
> Okay, so we'd potentially set it on thread creation only? That might not be
> too bad.
Basically, yes. A runtime _could_ set it at other times, and my view
is that the kernel shouldn't arbitrarily forbid this -- but it's up to
userspace to determine when it's safe to do it, ensure that there's no
VL-dependent data live in memory, and to arrange to reallocate stacks
or pre-arrange that allocations were already big enough etc.
> I really want to avoid a repeat of the setxid fiasco, where we need to run
> code on all threads to get something that approximates the POSIX-mandated
> behavior (process attribute) from what the kernel provides (thread/task
> attribute).
Yeah, that would suck.
However, for the proposed ABI there is no illusion to preserve here,
since the VL is proposed as a per-thread property everywhere, and this
is outside the scope of POSIX.
If we do have distinct "set process VL" and "set thread VL" interfaces,
then my view is that the former should fail if there are already
multiple threads, rather than just setting the VL of a single thread or
(worse) asynchronously changing the VL of threads other than the
caller...
> >I'm not familiar with resumable functions/executors -- are these in
> >the C++ standards yet (not that that would cause me to be familiar
> >with them... ;) Any implementation of coroutines (i.e.,
> >cooperative switching) is likely to fall under the "setcontext"
> >argument above.
>
> There are different ways to implement coroutines. Stack switching (like
> setcontext) is obviously impacted by non-uniform register sizes. But even
> the most conservative variant, rather similar to switch-based emulation you
> sometimes see in C coroutine implementations, might have trouble restoring
> the state if it just cannot restore the saved state due to register size
> reductions.
Which is not a problem if the variably-sized state is not part of the
switched context?
Because the SVE procedure call standard determines that the SVE
registers are caller-save, they are not live at any external function
boundary -- so in cooperative switching it is useless to save/restore
this state unless the coroutine framework is defined to have a special
procedure call standard.
Similarly, my view is that we don't attempt to magically save and
restore VL itself either. Code that changes VL after startup would be
expected to be aware of and deal with the consequences itself.
Cheers
---Dave
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 3)
From: Arnd Bergmann @ 2016-11-30 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-5-nsekhar@ti.com>
On Monday, November 28, 2016 5:12:19 PM CET Sekhar Nori wrote:
> A patch enabling USB OHCI support in davinci
> defconfig.
>
>
Pulled into next/defconfig, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 3)
From: Arnd Bergmann @ 2016-11-30 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-3-nsekhar@ti.com>
On Monday, November 28, 2016 5:12:17 PM CET Sekhar Nori wrote:
> mach-davinci SoC support updates to adjust
> USB ohci device name to that used by drivers
> and update of various board files to use gpio
> descriptor API used by MMC subsystem for card
> detect and write-protect detection.
>
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 2)
From: Arnd Bergmann @ 2016-11-30 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-2-nsekhar@ti.com>
On Sunday, November 20, 2016 7:10:36 PM CET Sekhar Nori wrote:
> The following changes since commit ced95ac0815501f47a6041548d70d8900400912d:
>
> ARM: davinci: da8xx: register USB PHY clocks in the DT file (2016-11-01 15:24:24 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git davinci-for-v4.10/soc-2
>
> for you to fetch changes up to 7e431af8fa0b9ed9d74378c99514856211cb9db8:
>
> ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +0530)
>
> ----------------------------------------------------------------
> Adds suspend-to-RAM support for DT boot mode
> on DA850.
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [GIT PULL 1/4] DaVinci cleanups for v4.10 (part 2)
From: Arnd Bergmann @ 2016-11-30 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161120134038.14998-1-nsekhar@ti.com>
On Sunday, November 20, 2016 7:10:35 PM CET Sekhar Nori wrote:
> mach-davinci cleanup to make it easy to add PM support
> for DT-boot.
>
>
Pulled into next/soc, thanks!
Arnd
^ permalink raw reply
* [PATCH] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Jintack Lim @ 2016-11-30 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <129e316b-0a05-9114-f29f-c8935144720c@arm.com>
On Wed, Nov 30, 2016 at 8:31 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 29/11/16 21:05, Jintack Lim wrote:
>> On Tue, Nov 29, 2016 at 11:53 AM, Suzuki K Poulose
>> <suzuki.poulose@arm.com> wrote:
>>> On 29/11/16 09:36, Marc Zyngier wrote:
>>>>
>>>> On 29/11/16 03:28, Jintack Lim wrote:
>>>>>
>>>>> On Mon, Nov 28, 2016 at 1:39 PM, Marc Zyngier <marc.zyngier@arm.com>
>>>>> wrote:
>>>>>>
>>>>>> On 28/11/16 17:43, Marc Zyngier wrote:
>>>>>
>>>>> This looks much cleaner than my patch.
>>>>> While we are at it, is it worth to consider that we just need to set
>>>>> those bits once for VHE case, not for every world switch as an
>>>>> optimization?
>>>>
>>>>
>>>> Ah! That's a much better idea indeed! And we could stop messing with
>>>> cntvoff_el2 as well, as it doesn't need to be restored to zero on exit.
>>>> Could you try and respin something along those lines?
>>>>
>>>
>>> fyi, we have a static_key based cpus_have_const_cap() for Constant cap
>>> checking (like this case) available in linux-next. May be you could make use
>>> of that instead of alternatives.
>>
>> Thanks Suzuki. This looks very useful.
>>
>> Marc, can I write a patch based on linux-next? The commit which has
>> cpus_have_const_cap() is not in master and next branch in kvm/arm
>> repo.
>
> You can. It is just that I won't be able to apply it immediately (I'll
> wait for -rc1 to be out, and send it as a fix).
Ok. Thanks!. I'll send out v2.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
>
^ permalink raw reply
* [PATCH 1/1] usb: return error code when platform_get_irq fails
From: Matthias Brugger @ 2016-11-30 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480424255-25059-1-git-send-email-bianpan2016@163.com>
On 29/11/16 13:57, Pan Bian wrote:
> In function xhci_mtk_probe(), variable ret takes the return value. Its
> value should be negative on failures. However, when the call to function
> platform_get_irq() fails, it does not set the error code, and 0 will be
> returned. 0 indicates no error. As a result, the callers of function
> xhci_mtk_probe() will not be able to detect the error. This patch fixes
> the bug by assigning the return value of platform_get_irq() to variable
> ret if it fails.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> drivers/usb/host/xhci-mtk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> index 79959f1..f2365a4 100644
> --- a/drivers/usb/host/xhci-mtk.c
> +++ b/drivers/usb/host/xhci-mtk.c
> @@ -560,8 +560,10 @@ static int xhci_mtk_probe(struct platform_device *pdev)
> goto disable_ldos;
>
> irq = platform_get_irq(pdev, 0);
> - if (irq < 0)
> + if (irq < 0) {
> + ret = irq;
> goto disable_clk;
> + }
>
> /* Initialize dma_mask and coherent_dma_mask to 32-bits */
> ret = dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Next time please make sure to send the patch to all relevant lists and
people (get_maintainer.pl).
Regards,
Matthias
^ permalink raw reply
* Unable to use perf in VM
From: Marc Zyngier @ 2016-11-30 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b2a3cfd-57a0-70ac-ef50-672f8040291d@arm.com>
On 30/11/16 11:48, Marc Zyngier wrote:
> + Shannon
>
> On 29/11/16 22:04, Itaru Kitayama wrote:
>> Hi,
>>
>> In a VM (virsh controlled, KVM acceleration enabled) on a recent
>> kvmarm kernel host, I find I am unable to use perf to obtain
>> performance statistics for a complex task like kernel build.
>> (I've verified this is seen with a Fedora 25 VM and host combination
>> as well)
>> APM folks CC'ed think this might be caused by a bug in the core PMU
>> framework code, thus I'd like to have experts opinion on this issue.
>>
>> [root at localhost linux]# perf stat -B make
>> CHK include/config/kernel.release
>> [ 119.617684] git[1144]: undefined instruction: pc=fffffc000808ff30
>> [ 119.623040] Code: 51000442 92401042 d51b9ca2 d5033fdf (d53b9d40)
>> [ 119.627607] Internal error: undefined instruction: 0 [#1] SMP
>
> [...]
>
> In a VM running mainline hosted on an AMD Seattle box:
>
> Performance counter stats for 'make':
>
> 1526089.499304 task-clock:u (msec) # 0.932 CPUs utilized
> 0 context-switches:u # 0.000 K/sec
> 0 cpu-migrations:u # 0.000 K/sec
> 29527793 page-faults:u # 0.019 M/sec
> 2913174122673 cycles:u # 1.909 GHz
> 2365040892322 instructions:u # 0.81 insn per cycle
> <not supported> branches:u
> 32049215378 branch-misses:u # 0.00% of all branches
>
> 1637.531444837 seconds time elapsed
>
> Running the same host kernel on a Mustang system, the guest explodes
> in the way you reported. The failing instruction always seems to be
> an access to pmxevcntr_el0 (I've seen both reads and writes).
>
> Funnily enough, it dies if you try any HW event other than cycles
> ("perf stat -e cycles ls" works, and "perf stat -e instructions ls"
> explodes). Which would tend to indicate that we're screwing up
> the counter selection, but I have no proof of that (specially that
> the Seattle guest is working just as expected).
It turns out that we *don't* inject an undef. It seems to be generated
locally at EL1.
Still digging.
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] crypto: arm/aesbs - fix brokenness after skcipher conversion
From: Ard Biesheuvel @ 2016-11-30 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130131921.GD4126@gondor.apana.org.au>
> On 30 Nov 2016, at 13:19, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
>> On Tue, Nov 29, 2016 at 05:23:36PM +0000, Ard Biesheuvel wrote:
>> The CBC encryption routine should use the encryption round keys, not
>> the decryption round keys.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Patch applied. Thanks.
>
>> Another fix for the queued changes, this time for 32-bit ARM.
>>
>> I must say, I'm not impressed with the level of testing that has been
>> carried out after applying these changes. If you had cc'd me on these
>> patches, I would have been happy to test/review.
>
> Sorry. I'll make sure you're CCed for ARM patches in future.
Cheers,
Ard.
^ permalink raw reply
* [PATCH] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Marc Zyngier @ 2016-11-30 13:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHyh4xi2oq8m2B_3oZu+BNeyk-++L2ziMY66+XZ+SDRjOHDN6A@mail.gmail.com>
On 29/11/16 21:05, Jintack Lim wrote:
> On Tue, Nov 29, 2016 at 11:53 AM, Suzuki K Poulose
> <suzuki.poulose@arm.com> wrote:
>> On 29/11/16 09:36, Marc Zyngier wrote:
>>>
>>> On 29/11/16 03:28, Jintack Lim wrote:
>>>>
>>>> On Mon, Nov 28, 2016 at 1:39 PM, Marc Zyngier <marc.zyngier@arm.com>
>>>> wrote:
>>>>>
>>>>> On 28/11/16 17:43, Marc Zyngier wrote:
>>>>
>>>> This looks much cleaner than my patch.
>>>> While we are at it, is it worth to consider that we just need to set
>>>> those bits once for VHE case, not for every world switch as an
>>>> optimization?
>>>
>>>
>>> Ah! That's a much better idea indeed! And we could stop messing with
>>> cntvoff_el2 as well, as it doesn't need to be restored to zero on exit.
>>> Could you try and respin something along those lines?
>>>
>>
>> fyi, we have a static_key based cpus_have_const_cap() for Constant cap
>> checking (like this case) available in linux-next. May be you could make use
>> of that instead of alternatives.
>
> Thanks Suzuki. This looks very useful.
>
> Marc, can I write a patch based on linux-next? The commit which has
> cpus_have_const_cap() is not in master and next branch in kvm/arm
> repo.
You can. It is just that I won't be able to apply it immediately (I'll
wait for -rc1 to be out, and send it as a fix).
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/1] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Russell King - ARM Linux @ 2016-11-30 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480502428-19509-1-git-send-email-maninder1.s@samsung.com>
On Wed, Nov 30, 2016 at 04:10:28PM +0530, Maninder Singh wrote:
> variable name can have Non NULL terminated string after cropping
> which may result strcat to fail, and cropping is not
> required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
>
> Issue caught with static analysis tool:
> "Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
Maybe switch to strlcpy() ?
>
> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index 759e1d4..8adf272 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -742,12 +742,15 @@ static int _init_main_clk(struct omap_hwmod *oh)
> char name[MOD_CLK_MAX_NAME_LEN];
> struct clk *clk;
>
> - /* +7 magic comes from '_mod_ck' suffix */
> - if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
> + /* +8 magic comes from strlen("_mod_ck") added as suffix */
> + if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
> pr_warn("%s: warning: cropping name for %s\n", __func__,
> oh->name);
> + strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 8);
> + name[MOD_CLK_MAX_NAME_LEN - 8] = '\0';
> + } else
> + strcpy(name, oh->name);
>
> - strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
> strcat(name, "_mod_ck");
>
> clk = clk_get(NULL, name);
> --
> 1.9.1
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 3/4] crypto: arm64/aes-ce-ccm - fix decrypt path with new skcipher interface
From: Ard Biesheuvel @ 2016-11-30 13:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130131407.GA3958@gondor.apana.org.au>
On 30 November 2016 at 13:14, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Tue, Nov 29, 2016 at 01:05:32PM +0000, Ard Biesheuvel wrote:
>> The new skcipher walk interface does not take into account whether we
>> are encrypting or decrypting. In the latter case, the walk should
>> disregard the MAC. Fix this in the arm64 CE driver.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Thanks for the patch. I'm going to build this into the AEAD walker
> instead, by providing separate entry points for encryption and
> decryption. Like this,
>
Yes, that's better, thanks
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---8<---
> Subject: crypto: skcipher - Add separate walker for AEAD decryption
>
> The AEAD decrypt interface includes the authentication tag in
> req->cryptlen. Therefore we need to exlucde that when doing
> a walk over it.
>
> This patch adds separate walker functions for AEAD encryption
> and decryption.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/crypto/skcipher.c b/crypto/skcipher.c
> index 5367f81..aca07c6 100644
> --- a/crypto/skcipher.c
> +++ b/crypto/skcipher.c
> @@ -500,8 +500,8 @@ int skcipher_walk_async(struct skcipher_walk *walk,
> }
> EXPORT_SYMBOL_GPL(skcipher_walk_async);
>
> -int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
> - bool atomic)
> +static int skcipher_walk_aead_common(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic)
> {
> struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> int err;
> @@ -514,7 +514,6 @@ int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
> scatterwalk_copychunks(NULL, &walk->in, req->assoclen, 2);
> scatterwalk_copychunks(NULL, &walk->out, req->assoclen, 2);
>
> - walk->total = req->cryptlen;
> walk->iv = req->iv;
> walk->oiv = req->iv;
>
> @@ -535,8 +534,36 @@ int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
>
> return err;
> }
> +
> +int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
> + bool atomic)
> +{
> + walk->total = req->cryptlen;
> +
> + return skcipher_walk_aead_common(walk, req, atomic);
> +}
> EXPORT_SYMBOL_GPL(skcipher_walk_aead);
>
> +int skcipher_walk_aead_encrypt(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic)
> +{
> + walk->total = req->cryptlen;
> +
> + return skcipher_walk_aead_common(walk, req, atomic);
> +}
> +EXPORT_SYMBOL_GPL(skcipher_walk_aead_encrypt);
> +
> +int skcipher_walk_aead_decrypt(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic)
> +{
> + struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> +
> + walk->total = req->cryptlen - crypto_aead_authsize(tfm);
> +
> + return skcipher_walk_aead_common(walk, req, atomic);
> +}
> +EXPORT_SYMBOL_GPL(skcipher_walk_aead_decrypt);
> +
> static unsigned int crypto_skcipher_extsize(struct crypto_alg *alg)
> {
> if (alg->cra_type == &crypto_blkcipher_type)
> diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
> index d55041f..8735979 100644
> --- a/include/crypto/internal/skcipher.h
> +++ b/include/crypto/internal/skcipher.h
> @@ -149,6 +149,10 @@ int skcipher_walk_async(struct skcipher_walk *walk,
> struct skcipher_request *req);
> int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
> bool atomic);
> +int skcipher_walk_aead_encrypt(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic);
> +int skcipher_walk_aead_decrypt(struct skcipher_walk *walk,
> + struct aead_request *req, bool atomic);
> void skcipher_walk_complete(struct skcipher_walk *walk, int err);
>
> static inline void ablkcipher_request_complete(struct ablkcipher_request *req,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: arm/aesbs - fix brokenness after skcipher conversion
From: Herbert Xu @ 2016-11-30 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480440216-341-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Nov 29, 2016 at 05:23:36PM +0000, Ard Biesheuvel wrote:
> The CBC encryption routine should use the encryption round keys, not
> the decryption round keys.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patch applied. Thanks.
> Another fix for the queued changes, this time for 32-bit ARM.
>
> I must say, I'm not impressed with the level of testing that has been
> carried out after applying these changes. If you had cc'd me on these
> patches, I would have been happy to test/review.
Sorry. I'll make sure you're CCed for ARM patches in future.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 1/4] crypto: arm/aes-ce: fix broken monolithic build
From: Herbert Xu @ 2016-11-30 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480424733-10797-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Nov 29, 2016 at 01:05:30PM +0000, Ard Biesheuvel wrote:
> When building the arm64 kernel with both CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
> and CONFIG_CRYPTO_AES_ARM64_NEON_BLK=y configured, the build breaks with
> the following error:
>
> arch/arm64/crypto/aes-neon-blk.o:(.bss+0x0): multiple definition of `aes_simd_algs'
> arch/arm64/crypto/aes-ce-blk.o:(.bss+0x0): first defined here
>
> Fix this by making aes_simd_algs 'static'.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Patches 1,2 and 4 applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 3/4] crypto: arm64/aes-ce-ccm - fix decrypt path with new skcipher interface
From: Herbert Xu @ 2016-11-30 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130131407.GA3958@gondor.apana.org.au>
On Wed, Nov 30, 2016 at 09:14:07PM +0800, Herbert Xu wrote:
> On Tue, Nov 29, 2016 at 01:05:32PM +0000, Ard Biesheuvel wrote:
> > The new skcipher walk interface does not take into account whether we
> > are encrypting or decrypting. In the latter case, the walk should
> > disregard the MAC. Fix this in the arm64 CE driver.
> >
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> Thanks for the patch. I'm going to build this into the AEAD walker
> instead, by providing separate entry points for encryption and
> decryption. Like this,
>
> Subject: crypto: skcipher - Add separate walker for AEAD decryption
---8<---
Subject: crypto: arm64/aes-ce-ccm - Fix AEAD decryption length
This patch fixes the ARM64 CE CCM implementation decryption by
using skcipher_walk_aead_decrypt instead of skcipher_walk_aead,
which ensures the correct length is used when doing the walk.
Fixes: cf2c0fe74084 ("crypto: aes-ce-ccm - Use skcipher walk interface")
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c b/arch/arm64/crypto/aes-ce-ccm-glue.c
index d4f3568..cc5515d 100644
--- a/arch/arm64/crypto/aes-ce-ccm-glue.c
+++ b/arch/arm64/crypto/aes-ce-ccm-glue.c
@@ -167,7 +167,7 @@ static int ccm_encrypt(struct aead_request *req)
/* preserve the original iv for the final round */
memcpy(buf, req->iv, AES_BLOCK_SIZE);
- err = skcipher_walk_aead(&walk, req, true);
+ err = skcipher_walk_aead_encrypt(&walk, req, true);
while (walk.nbytes) {
u32 tail = walk.nbytes % AES_BLOCK_SIZE;
@@ -219,7 +219,7 @@ static int ccm_decrypt(struct aead_request *req)
/* preserve the original iv for the final round */
memcpy(buf, req->iv, AES_BLOCK_SIZE);
- err = skcipher_walk_aead(&walk, req, true);
+ err = skcipher_walk_aead_decrypt(&walk, req, true);
while (walk.nbytes) {
u32 tail = walk.nbytes % AES_BLOCK_SIZE;
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* arasan,sdhci.txt "compatibility" DT binding
From: Michal Simek @ 2016-11-30 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <648bd95b-5be0-b39f-a956-af741c6407e4@laposte.net>
On 30.11.2016 11:51, Sebastian Frias wrote:
> On 29/11/16 08:29, Rameshwar Sahu wrote:
>> Hi Mason,
>>
>> Nowhere in the documentation do they specify an "IP version".
>> Some documents do provide a revision number, but that's just
>> a *documentation* revision number, e.g.
>>
>> changes in version 3.6 : fix typos
>> changes in version 9.1a : update company logo
>>
>> That's why Xilinx used "arasan,sdhci-8.9a" and APM used
>> "arasan,sdhci-4.9a". These are documentation revisions.
>> In my opinion, that information is mostly worthless.
>>
>
> For the record, the important information conveyed by Rameshwar's
> email is the following:
>
> Arasan SD/SDIO/eMMC IP has a register which tells about the SD
> specification version and Vendor version number
> Reg Name: Host controller version register (offset 0FEh)
> bit [15:8] is for vendor version number,
> But, I have seen that Arasaan vendor version number is same as
> document revision number.
>
> (At first I had ignored the email because it repeated Mason's email
> without quoting, but then I realised it contained some information)
>
>
Values on real HW.
ZynqMP device
xsdb% mrd 0xFF1600FC
FF1600FC: 10020000
Zynq device:
xsdb% mrd 0xE01000FC
E01000FC: 89010000
Based on docs I have access to.
Specification_Version_Number (bits:23:16)
00 - SD Host Specification version 1.0
01 - SD Host Specification version 2.00 including only the feature of
the Test Register
02 - SD Host Specification version 3.00
Vendor_Version_Number 31:24
with 32bit access from FC
Thanks,
Michal
^ permalink raw reply
* [PATCH 3/4] crypto: arm64/aes-ce-ccm - fix decrypt path with new skcipher interface
From: Herbert Xu @ 2016-11-30 13:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480424733-10797-3-git-send-email-ard.biesheuvel@linaro.org>
On Tue, Nov 29, 2016 at 01:05:32PM +0000, Ard Biesheuvel wrote:
> The new skcipher walk interface does not take into account whether we
> are encrypting or decrypting. In the latter case, the walk should
> disregard the MAC. Fix this in the arm64 CE driver.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Thanks for the patch. I'm going to build this into the AEAD walker
instead, by providing separate entry points for encryption and
decryption. Like this,
---8<---
Subject: crypto: skcipher - Add separate walker for AEAD decryption
The AEAD decrypt interface includes the authentication tag in
req->cryptlen. Therefore we need to exlucde that when doing
a walk over it.
This patch adds separate walker functions for AEAD encryption
and decryption.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index 5367f81..aca07c6 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -500,8 +500,8 @@ int skcipher_walk_async(struct skcipher_walk *walk,
}
EXPORT_SYMBOL_GPL(skcipher_walk_async);
-int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
- bool atomic)
+static int skcipher_walk_aead_common(struct skcipher_walk *walk,
+ struct aead_request *req, bool atomic)
{
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
int err;
@@ -514,7 +514,6 @@ int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
scatterwalk_copychunks(NULL, &walk->in, req->assoclen, 2);
scatterwalk_copychunks(NULL, &walk->out, req->assoclen, 2);
- walk->total = req->cryptlen;
walk->iv = req->iv;
walk->oiv = req->iv;
@@ -535,8 +534,36 @@ int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
return err;
}
+
+int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
+ bool atomic)
+{
+ walk->total = req->cryptlen;
+
+ return skcipher_walk_aead_common(walk, req, atomic);
+}
EXPORT_SYMBOL_GPL(skcipher_walk_aead);
+int skcipher_walk_aead_encrypt(struct skcipher_walk *walk,
+ struct aead_request *req, bool atomic)
+{
+ walk->total = req->cryptlen;
+
+ return skcipher_walk_aead_common(walk, req, atomic);
+}
+EXPORT_SYMBOL_GPL(skcipher_walk_aead_encrypt);
+
+int skcipher_walk_aead_decrypt(struct skcipher_walk *walk,
+ struct aead_request *req, bool atomic)
+{
+ struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+
+ walk->total = req->cryptlen - crypto_aead_authsize(tfm);
+
+ return skcipher_walk_aead_common(walk, req, atomic);
+}
+EXPORT_SYMBOL_GPL(skcipher_walk_aead_decrypt);
+
static unsigned int crypto_skcipher_extsize(struct crypto_alg *alg)
{
if (alg->cra_type == &crypto_blkcipher_type)
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index d55041f..8735979 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -149,6 +149,10 @@ int skcipher_walk_async(struct skcipher_walk *walk,
struct skcipher_request *req);
int skcipher_walk_aead(struct skcipher_walk *walk, struct aead_request *req,
bool atomic);
+int skcipher_walk_aead_encrypt(struct skcipher_walk *walk,
+ struct aead_request *req, bool atomic);
+int skcipher_walk_aead_decrypt(struct skcipher_walk *walk,
+ struct aead_request *req, bool atomic);
void skcipher_walk_complete(struct skcipher_walk *walk, int err);
static inline void ablkcipher_request_complete(struct ablkcipher_request *req,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* [PATCH v2 3/3] ARM: dts: da850: Add node for pullup/pulldown pinconf
From: Linus Walleij @ 2016-11-30 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-4-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This SoC has a separate pin controller for configuring pullup/pulldown
> bias on groups of pins.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
>
> v2 changes:
> * Moved pin-controller at 22c00c device node after gpio at 226000 (there seem to be
> more nodes in proper order here compared to the i2c at 228000 node suggested by
> Sekhar)
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Take this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/3] pinctrl: New driver for TI DA850/OMAP-L138/AM18XX pinconf
From: Linus Walleij @ 2016-11-30 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-3-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> This adds a new driver for pinconf on TI DA850/OMAP-L138/AM18XX. These
> SoCs have a separate controller for controlling pullup/pulldown groups.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/3] devicetree: bindings: pinctrl: Add binding for ti, da850-pupd
From: Linus Walleij @ 2016-11-30 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480351226-3332-2-git-send-email-david@lechnology.com>
On Mon, Nov 28, 2016 at 5:40 PM, David Lechner <david@lechnology.com> wrote:
> Device-tree bindings for TI DA850/OMAP-L138/AM18XX pullup/pulldown
> pinconf controller.
>
> Signed-off-by: David Lechner <david@lechnology.com>
> Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Totally uncontroversial standard bindings so patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Robin Murphy @ 2016-11-30 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8e91ce72-9d37-f4be-9224-856a1a4c3e1d@samsung.com>
On 30/11/16 07:54, Marek Szyprowski wrote:
> Hi Sricharan and Robin,
>
>
> On 2016-11-30 01:22, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart
>> <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: massive PCI hacks]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/base/dma-mapping.c | 4 ++--
>> drivers/iommu/dma-iommu.c | 1 +
>> drivers/iommu/of_iommu.c | 5 +++--
>> drivers/of/device.c | 9 +++++++--
>> drivers/pci/probe.c | 6 ++++--
>> include/linux/of_device.h | 9 ++++++---
>> include/linux/pci.h | 4 ++--
>> 7 files changed, 25 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
>> index b2a5629..576fdfb 100644
>> --- a/drivers/base/dma-mapping.c
>> +++ b/drivers/base/dma-mapping.c
>> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t
>> size, unsigned long vm_flags)
>> int dma_configure(struct device *dev)
>> {
>> if (dev_is_pci(dev))
>> - pci_dma_configure(dev);
>> + return pci_dma_configure(dev);
>> else if (dev->of_node)
>> - of_dma_configure(dev, dev->of_node);
>> + return of_dma_configure(dev, dev->of_node);
>> return 0;
>> }
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..d2a7a46 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain
>> *domain, dma_addr_t base,
>> base_pfn = max_t(unsigned long, 1, base >> order);
>> end_pfn = (base + size - 1) >> order;
>> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n",
>> base, size, domain->geometry.aperture_start,
>> domain->geometry.aperture_end,
>
> This causes a NULL pointer dereference if caller passes NULL device
> pointer.
> There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
> Trivial to fix as it looks like a leftover from developement or
> debugging stage.
Yes, this is some development crap which was never intended to go
upstream. Hence "massive PCI hacks" ;)
Other than the first two patches, the rest of the stuff from me here was
just an experiment which I'm not entirely convinced by the outcome of -
I don't particularly like the resulting fragmentation of having
pci_dma_configure() awkwardly floating around on its own in pci.c.
Robin.
>> *dev->dma_mask, dev->coherent_dma_mask);
>> /* Check the domain allows at least some access to the device... */
>> if (domain->geometry.force_aperture) {
>> if (base > domain->geometry.aperture_end ||
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 349bd1d..9529d6c 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>> #include <linux/of.h>
>> #include <linux/of_iommu.h>
>> #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>> #include <linux/slab.h>
>> static const struct of_device_id __iommu_of_table_sentinel
>> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct
>> device *dev,
>> ops = ERR_PTR(err);
>> }
>> - return IS_ERR(ops) ? NULL : ops;
>> + return ops;
>> }
>> static int __init of_iommu_init(void)
>> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
>> for_each_matching_node_and_match(np, matches, &match) {
>> const of_iommu_init_fn init_fn = match->data;
>> - if (init_fn(np))
>> + if (init_fn && init_fn(np))
>> pr_err("Failed to initialise IOMMU %s\n",
>> of_node_full_name(np));
>> }
>> diff --git a/drivers/of/device.c b/drivers/of/device.c
>> index 1c843e2..d58595c 100644
>> --- a/drivers/of/device.c
>> +++ b/drivers/of/device.c
>> @@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
>> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE
>> events
>> * to fix up DMA configuration.
>> */
>> -void of_dma_configure(struct device *dev, struct device_node *np)
>> +int of_dma_configure(struct device *dev, struct device_node *np)
>> {
>> u64 dma_addr, paddr, size;
>> int ret;
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>> if (ret < 0) {
>> dma_addr = offset = 0;
>> - size = dev->coherent_dma_mask + 1;
>> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>> } else {
>> offset = PFN_DOWN(paddr - dma_addr);
>> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
>> @@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> coherent ? " " : " not ");
>> iommu = of_iommu_configure(dev, np);
>> + if (IS_ERR(iommu))
>> + return PTR_ERR(iommu);
>> +
>> dev_dbg(dev, "device is%sbehind an iommu\n",
>> iommu ? " " : " not ");
>> arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
>> +
>> + return 0;
>> }
>> EXPORT_SYMBOL_GPL(of_dma_configure);
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 04af770..6316cae 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -1724,13 +1724,14 @@ static void pci_set_msi_domain(struct pci_dev
>> *dev)
>> * Function to update PCI devices's DMA configuration using the same
>> * info from the OF node or ACPI node of host bridge's parent (if any).
>> */
>> -void pci_dma_configure(struct device *dev)
>> +int pci_dma_configure(struct device *dev)
>> {
>> struct device *bridge =
>> pci_get_host_bridge_device(to_pci_dev(dev));
>> + int ret = 0;
>> if (IS_ENABLED(CONFIG_OF) &&
>> bridge->parent && bridge->parent->of_node) {
>> - of_dma_configure(dev, bridge->parent->of_node);
>> + ret = of_dma_configure(dev, bridge->parent->of_node);
>> } else if (has_acpi_companion(bridge)) {
>> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
>> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
>> @@ -1742,6 +1743,7 @@ void pci_dma_configure(struct device *dev)
>> }
>> pci_put_host_bridge_device(bridge);
>> + return ret;
>> }
>> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
>> index d20a31a..6dca65c 100644
>> --- a/include/linux/of_device.h
>> +++ b/include/linux/of_device.h
>> @@ -55,7 +55,7 @@ static inline struct device_node
>> *of_cpu_device_node_get(int cpu)
>> return of_node_get(cpu_dev->of_node);
>> }
>> -void of_dma_configure(struct device *dev, struct device_node *np);
>> +int of_dma_configure(struct device *dev, struct device_node *np);
>> void of_dma_deconfigure(struct device *dev);
>> #else /* CONFIG_OF */
>> @@ -99,8 +99,11 @@ static inline struct device_node
>> *of_cpu_device_node_get(int cpu)
>> {
>> return NULL;
>> }
>> -static inline void of_dma_configure(struct device *dev, struct
>> device_node *np)
>> -{}
>> +
>> +static inline int of_dma_configure(struct device *dev, struct
>> device_node *np)
>> +{
>> + return 0;
>> +}
>> static inline void of_dma_deconfigure(struct device *dev)
>> {}
>> #endif /* CONFIG_OF */
>> diff --git a/include/linux/pci.h b/include/linux/pci.h
>> index d04f651..989ca44 100644
>> --- a/include/linux/pci.h
>> +++ b/include/linux/pci.h
>> @@ -870,7 +870,7 @@ struct resource *pci_find_parent_resource(const
>> struct pci_dev *dev,
>> #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn :
>> false))
>> #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
>> -void pci_dma_configure(struct device *dev);
>> +int pci_dma_configure(struct device *dev);
>> /* Generic PCI functions exported to card drivers */
>> @@ -1604,7 +1604,7 @@ static inline struct pci_dev
>> *pci_get_bus_and_slot(unsigned int bus,
>> #define dev_is_pf(d) (false)
>> #define dev_num_vf(d) (0)
>> -static inline void pci_dma_configure(struct device *dev) { }
>> +static inline int pci_dma_configure(struct device *dev) { return 0; }
>> #endif /* CONFIG_PCI */
>>
>
> Best regards
^ permalink raw reply
* [PATCH v3 2/2] ARM: tse850_defconfig: add Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
MAINTAINERS | 1 +
arch/arm/configs/tse850_defconfig | 223 ++++++++++++++++++++++++++++++++++++++
2 files changed, 224 insertions(+)
create mode 100644 arch/arm/configs/tse850_defconfig
diff --git a/MAINTAINERS b/MAINTAINERS
index 9dfe877f47e0..d8eb3843dbd4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2345,6 +2345,7 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: Documentation/devicetree/bindings/arm/axentia.txt
F: arch/arm/boot/dts/axentia-*
+F: arch/arm/configs/tse850_defconfig
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
diff --git a/arch/arm/configs/tse850_defconfig b/arch/arm/configs/tse850_defconfig
new file mode 100644
index 000000000000..f6076e7e1669
--- /dev/null
+++ b/arch/arm/configs/tse850_defconfig
@@ -0,0 +1,223 @@
+# CONFIG_LOCALVERSION_AUTO is not set
+# CONFIG_SWAP is not set
+CONFIG_SYSVIPC=y
+# CONFIG_FHANDLE is not set
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_EMBEDDED=y
+CONFIG_SLAB=y
+# CONFIG_LBDAF is not set
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_AT91=y
+CONFIG_SOC_SAMA5D3=y
+# CONFIG_CACHE_L2X0 is not set
+CONFIG_AEABI=y
+CONFIG_UACCESS_WITH_MEMCPY=y
+CONFIG_ZBOOT_ROM_TEXT=0x0
+CONFIG_ZBOOT_ROM_BSS=0x0
+CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
+CONFIG_KEXEC=y
+CONFIG_VFP=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_PACKET_DIAG=y
+CONFIG_UNIX=y
+CONFIG_UNIX_DIAG=y
+CONFIG_XFRM_USER=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPGRE_DEMUX=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+CONFIG_INET_UDP_DIAG=y
+# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET6_XFRM_MODE_BEET is not set
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=y
+# CONFIG_NF_CONNTRACK_PROCFS is not set
+CONFIG_NF_CONNTRACK_SNMP=y
+CONFIG_NF_TABLES=y
+CONFIG_NF_TABLES_INET=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_EXTHDR=y
+CONFIG_NFT_META=y
+CONFIG_NFT_NUMGEN=y
+CONFIG_NFT_CT=y
+CONFIG_NFT_SET_RBTREE=y
+CONFIG_NFT_SET_HASH=y
+CONFIG_NFT_COUNTER=y
+CONFIG_NFT_LOG=y
+CONFIG_NFT_LIMIT=y
+CONFIG_NFT_QUOTA=y
+CONFIG_NFT_REJECT=y
+CONFIG_NFT_HASH=y
+# CONFIG_WIRELESS is not set
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_DEVTMPFS=y
+CONFIG_DEVTMPFS_MOUNT=y
+# CONFIG_STANDALONE is not set
+# CONFIG_PREVENT_FIRMWARE_BUILD is not set
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_ATMEL=y
+CONFIG_MTD_UBI=y
+CONFIG_MTD_UBI_GLUEBI=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=4
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_ATMEL_TCLIB=y
+CONFIG_ATMEL_SSC=y
+CONFIG_EEPROM_AT24=y
+CONFIG_SCSI=y
+CONFIG_BLK_DEV_SD=y
+# CONFIG_SCSI_LOWLEVEL is not set
+CONFIG_NETDEVICES=y
+# CONFIG_NET_VENDOR_ARC is not set
+CONFIG_MACB=y
+# CONFIG_NET_VENDOR_BROADCOM is not set
+# CONFIG_NET_VENDOR_CIRRUS is not set
+# CONFIG_NET_VENDOR_EZCHIP is not set
+# CONFIG_NET_VENDOR_FARADAY is not set
+# CONFIG_NET_VENDOR_HISILICON is not set
+# CONFIG_NET_VENDOR_INTEL is not set
+# CONFIG_NET_VENDOR_MARVELL is not set
+# CONFIG_NET_VENDOR_MICREL is not set
+# CONFIG_NET_VENDOR_NATSEMI is not set
+# CONFIG_NET_VENDOR_QUALCOMM is not set
+# CONFIG_NET_VENDOR_RENESAS is not set
+# CONFIG_NET_VENDOR_ROCKER is not set
+# CONFIG_NET_VENDOR_SAMSUNG is not set
+# CONFIG_NET_VENDOR_SEEQ is not set
+# CONFIG_NET_VENDOR_SMSC is not set
+# CONFIG_NET_VENDOR_STMICRO is not set
+# CONFIG_NET_VENDOR_SYNOPSYS is not set
+# CONFIG_NET_VENDOR_VIA is not set
+# CONFIG_NET_VENDOR_WIZNET is not set
+CONFIG_MICREL_PHY=y
+# CONFIG_USB_NET_DRIVERS is not set
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_LEDS is not set
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_VT_HW_CONSOLE_BINDING=y
+CONFIG_LEGACY_PTY_COUNT=4
+CONFIG_SERIAL_ATMEL=y
+CONFIG_SERIAL_ATMEL_CONSOLE=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_AT91=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_RESET=y
+CONFIG_SENSORS_JC42=y
+CONFIG_WATCHDOG=y
+CONFIG_AT91SAM9X_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_PCM_OSS=y
+# CONFIG_SND_DRIVERS is not set
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_SND_ATMEL_SOC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=y
+# CONFIG_HID_GENERIC is not set
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_STORAGE=y
+CONFIG_USB_STORAGE_REALTEK=y
+CONFIG_USB_STORAGE_DATAFAB=y
+CONFIG_USB_STORAGE_FREECOM=y
+CONFIG_USB_STORAGE_ISD200=y
+CONFIG_USB_STORAGE_USBAT=y
+CONFIG_USB_STORAGE_SDDR09=y
+CONFIG_USB_STORAGE_SDDR55=y
+CONFIG_USB_STORAGE_JUMPSHOT=y
+CONFIG_USB_STORAGE_ALAUDA=y
+CONFIG_USB_STORAGE_ONETOUCH=y
+CONFIG_USB_STORAGE_KARMA=y
+CONFIG_USB_STORAGE_CYPRESS_ATACB=y
+CONFIG_USB_STORAGE_ENE_UB6250=y
+CONFIG_USB_UAS=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_ATMEL_USBA=y
+CONFIG_USB_G_SERIAL=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
+CONFIG_LEDS_TRIGGER_TIMER=y
+CONFIG_LEDS_TRIGGER_HEARTBEAT=y
+CONFIG_LEDS_TRIGGER_GPIO=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_AT91RM9200=y
+CONFIG_DMADEVICES=y
+CONFIG_AT_HDMAC=y
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_IIO=y
+CONFIG_AT91_ADC=y
+CONFIG_ENVELOPE_DETECTOR=y
+CONFIG_DPOT_DAC=y
+CONFIG_MCP4531=y
+CONFIG_PWM=y
+CONFIG_PWM_ATMEL=y
+CONFIG_PWM_ATMEL_TCB=y
+CONFIG_EXT4_FS=y
+CONFIG_FANOTIFY=y
+CONFIG_OVERLAY_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_UBIFS_FS=y
+CONFIG_UBIFS_FS_ADVANCED_COMPR=y
+CONFIG_NLS_CODEPAGE_437=y
+CONFIG_NLS_CODEPAGE_850=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_STRIP_ASM_SYMS=y
+CONFIG_DEBUG_FS=y
+CONFIG_DEBUG_MEMORY_INIT=y
+CONFIG_LOCKUP_DETECTOR=y
+CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+# CONFIG_FTRACE is not set
+CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_CCM=y
+CONFIG_CRYPTO_GCM=y
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_ECB=y
+CONFIG_CRYPTO_SHA1=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_ARC4=y
+CONFIG_CRYPTO_DEV_ATMEL_AES=y
+CONFIG_CRYPTO_DEV_ATMEL_TDES=y
+CONFIG_CRYPTO_DEV_ATMEL_SHA=y
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/2] ARM: dts: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480510102-24587-1-git-send-email-peda@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 7 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
5 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index 000000000000..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+============================================
+
+Linea CPU module
+----------------
+
+Required root node properties:
+compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+----------------
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 130e927824b5..9dfe877f47e0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2339,6 +2339,13 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda@axentia.se>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/axentia-*
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab@s-opensource.com>
M: Mauro Carvalho Chehab <mchehab@kernel.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 58a3024f7edc..8ca735b82891 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ axentia-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/axentia-linea.dtsi b/arch/arm/boot/dts/axentia-linea.dtsi
new file mode 100644
index 000000000000..5a47d847149c
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-linea.dtsi
@@ -0,0 +1,53 @@
+/*
+ * axentia-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&main {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom at 51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/axentia-tse850-3.dts b/arch/arm/boot/dts/axentia-tse850-3.dts
new file mode 100644
index 000000000000..4e7c8bea2873
--- /dev/null
+++ b/arch/arm/boot/dts/axentia-tse850-3.dts
@@ -0,0 +1,276 @@
+/*
+ * axentia-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2016 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda@axentia.se>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "axentia-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ };
+
+ ahb {
+ apb {
+ pinctrl at fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,ssc-controller = <&ssc0>;
+ axentia,audio-codec = <&pcm5142>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv at c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2 at 100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree at 180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs at 10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42 at 18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104 at 28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142 at 4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom at 50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy at 3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
^ permalink raw reply related
* [PATCH v3 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2016-11-30 12:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
changes v2 -> v3
- document the new compatible strings prefixed with "axentia,".
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed (the
last ones are currently in -next) I would like to have the
dts and the defconfig also upstreamed.
Cheers,
Peter
Peter Rosin (2):
ARM: dts: add devicetree for the Axentia TSE-850
ARM: tse850_defconfig: add Axentia TSE-850
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axentia-linea.dtsi | 53 +++++
arch/arm/boot/dts/axentia-tse850-3.dts | 276 ++++++++++++++++++++++
arch/arm/configs/tse850_defconfig | 223 +++++++++++++++++
6 files changed, 580 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/axentia-linea.dtsi
create mode 100644 arch/arm/boot/dts/axentia-tse850-3.dts
create mode 100644 arch/arm/configs/tse850_defconfig
--
2.1.4
^ 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