* [PATCH v6 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_periph_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_periph_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v6:
- Revert back A3700_REGS, as asked by Wolfram and define fm_mask
and hs_mask in the register layout. I moved the generic code
for fm_mask and hs_mask to a seperated commit (1/4)
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index dc9d0a6..0ded4bc 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -57,8 +57,12 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
+
/*
* I2C registers definitions
*/
@@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ .fm = ICR_BUSMODE_FM,
+ .hs = ICR_BUSMODE_HS,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
--
2.9.3
^ permalink raw reply related
* [PATCH v6 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130140017.26307-1-romain.perier@free-electrons.com>
So far, the bit masks for the fast and high speed mode were statically
defined. Some IP blocks might use different bits for these modes.
This commit introduces new fields in order to enable the definition of
different bit masks for these features. If these fields are undefined,
ICR_FM and ICR_HS are selected to preserve backward compatibility with
other IPs.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
drivers/i2c/busses/i2c-pxa.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..dc9d0a6 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -48,6 +48,8 @@ struct pxa_reg_layout {
u32 isar;
u32 ilcr;
u32 iwcr;
+ u32 fm;
+ u32 hs;
};
enum pxa_i2c_types {
@@ -193,6 +195,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +507,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
+ i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? pxa_reg_layout[i2c_type].fm : ICR_FM;
+ i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? pxa_reg_layout[i2c_type].hs : ICR_HS;
+
if (i2c_type != REGS_CE4100)
i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
--
2.9.3
^ permalink raw reply related
* [PATCH v6 0/4] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-30 14:00 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (4):
i2c: pxa: Add definition of fast and high speed modes via the regs
layout
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 26 +++++++++++++++++++++--
5 files changed, 48 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [RFC v3 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 and IOVA reserved regions
From: Robin Murphy @ 2016-11-30 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFpQJXVqStQwRkm9F=e+8UFxWsddcwgB=AyfnZXSSaOw3eyBUA@mail.gmail.com>
On 30/11/16 10:52, Ganapatrao Kulkarni wrote:
> On Wed, Nov 30, 2016 at 3:44 PM, Auger Eric <eric.auger@redhat.com> wrote:
>> Hi Ganapat,
>>
>> On 30/11/2016 11:04, Ganapatrao Kulkarni wrote:
>>> Hi Eric,
>>>
>>> in you repo "https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3"
>>> there is 11th patch "pci: Enable overrides for missing ACS capabilities"
>>> is this patch part of some other series?
>>
>> Actually this is a very old patch from Alex aimed at working around lack
>> of PCIe ACS support: https://lkml.org/lkml/2013/5/30/513
>>
>
> i have tried this patchset on thunderx-83xx for vfio and it works for me!
> i was wondering is this patch required? i guess not.
If your system and devices actually support and properly advertise ACS
then there's nothing to override. Conversely, if you're happy assigning
everything behind a single RC to the same guest then ACS doesn't really
matter. It's only the in-between case - when the host still wants to
keep control of one or more devices, but they all get grouped together
due to lack of ACS - that warrants working around.
Robin.
>
> please cc me when you respin this patchset.
>
> thanks
> Ganapat
>
>> Thanks
>>
>> Eric
>>>
>>> thanks
>>> Ganapat
>>>
>>> On Wed, Nov 30, 2016 at 3:19 PM, Auger Eric <eric.auger@redhat.com> wrote:
>>>> Hi,
>>>>
>>>> On 15/11/2016 14:09, Eric Auger wrote:
>>>>> Following LPC discussions, we now report reserved regions through
>>>>> iommu-group sysfs reserved_regions attribute file.
>>>>>
>>>>> Reserved regions are populated through the IOMMU get_resv_region callback
>>>>> (former get_dm_regions), now implemented by amd-iommu, intel-iommu and
>>>>> arm-smmu.
>>>>>
>>>>> The intel-iommu reports the [FEE0_0000h - FEF0_000h] MSI window as an
>>>>> IOMMU_RESV_NOMAP reserved region.
>>>>>
>>>>> arm-smmu reports the MSI window (arbitrarily located at 0x8000000 and
>>>>> 1MB large) and the PCI host bridge windows.
>>>>>
>>>>> The series integrates a not officially posted patch from Robin:
>>>>> "iommu/dma: Allow MSI-only cookies".
>>>>>
>>>>> This series currently does not address IRQ safety assessment.
>>>>
>>>> I will respin this series taking into account Joerg's comment. Does
>>>> anyone have additional comments or want to put forward some conceptual
>>>> issues with the current direction and with this implementation?
>>>>
>>>> As for the IRQ safety assessment, in a first step I would propose to
>>>> remove the IOMMU_CAP_INTR_REMAP from arm-smmus and consider the
>>>> assignment as unsafe. Any objection?
>>>>
>>>> Thanks
>>>>
>>>> Eric
>>>>
>>>>
>>>>> Best Regards
>>>>>
>>>>> Eric
>>>>>
>>>>> Git: complete series available at
>>>>> https://github.com/eauger/linux/tree/v4.9-rc5-reserved-rfc-v3
>>>>>
>>>>> History:
>>>>> RFC v2 -> v3:
>>>>> - switch to an iommu-group sysfs API
>>>>> - use new dummy allocator provided by Robin
>>>>> - dummy allocator initialized by vfio-iommu-type1 after enumerating
>>>>> the reserved regions
>>>>> - at the moment ARM MSI base address/size is left unchanged compared
>>>>> to v2
>>>>> - we currently report reserved regions and not usable IOVA regions as
>>>>> requested by Alex
>>>>>
>>>>> RFC v1 -> v2:
>>>>> - fix intel_add_reserved_regions
>>>>> - add mutex lock/unlock in vfio_iommu_type1
>>>>>
>>>>>
>>>>> Eric Auger (10):
>>>>> iommu/dma: Allow MSI-only cookies
>>>>> iommu: Rename iommu_dm_regions into iommu_resv_regions
>>>>> iommu: Add new reserved IOMMU attributes
>>>>> iommu: iommu_alloc_resv_region
>>>>> iommu: Do not map reserved regions
>>>>> iommu: iommu_get_group_resv_regions
>>>>> iommu: Implement reserved_regions iommu-group sysfs file
>>>>> iommu/vt-d: Implement reserved region get/put callbacks
>>>>> iommu/arm-smmu: Implement reserved region get/put callbacks
>>>>> vfio/type1: Get MSI cookie
>>>>>
>>>>> drivers/iommu/amd_iommu.c | 20 +++---
>>>>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++
>>>>> drivers/iommu/dma-iommu.c | 116 ++++++++++++++++++++++++++-------
>>>>> drivers/iommu/intel-iommu.c | 50 ++++++++++----
>>>>> drivers/iommu/iommu.c | 141 ++++++++++++++++++++++++++++++++++++----
>>>>> drivers/vfio/vfio_iommu_type1.c | 26 ++++++++
>>>>> include/linux/dma-iommu.h | 7 ++
>>>>> include/linux/iommu.h | 49 ++++++++++----
>>>>> 8 files changed, 391 insertions(+), 70 deletions(-)
>>>>>
>>>>
>>>> _______________________________________________
>>>> linux-arm-kernel mailing list
>>>> linux-arm-kernel at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [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
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