* [PATCH] arm/xen: Use alloc_percpu rather than __alloc_percpu
From: Stefano Stabellini @ 2016-12-07 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481113480-7663-1-git-send-email-julien.grall@arm.com>
On Wed, 7 Dec 2016, Julien Grall wrote:
> The function xen_guest_init is using __alloc_percpu with an alignment
> which are not power of two.
>
> However, the percpu allocator never supported alignments which are not power
> of two and has always behaved incorectly in thise case.
>
> Commit 3ca45a4 "percpu: ensure requested alignment is power of two"
> introduced a check which trigger a warning [1] when booting linux-next
> on Xen. But in fine this bug was always present.
>
> This can be fixed by replacing the call to __alloc_percpu with
> alloc_percpu. The latter will use an alignment which are a power of two.
>
> [1]
>
> [ 0.023921] illegal size (48) or align (48) for percpu allocation
> [ 0.024167] ------------[ cut here ]------------
> [ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0
> [ 0.024584] Modules linked in:
> [ 0.024708]
> [ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> 4.9.0-rc7-next-20161128 #473
> [ 0.025012] Hardware name: Foundation-v8A (DT)
> [ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000
> [ 0.025351] PC is at pcpu_alloc+0x88/0x6c0
> [ 0.025490] LR is at pcpu_alloc+0x88/0x6c0
> [ 0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>]
> pstate: 60000045
> [ 0.025830] sp : ffff80003d847cd0
> [ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000
> [ 0.026147] x27: 0000000000000000 x26: 0000000000000000
> [ 0.026348] x25: 0000000000000000 x24: 0000000000000000
> [ 0.026549] x23: 0000000000000000 x22: 00000000024000c0
> [ 0.026752] x21: ffff000008e97000 x20: 0000000000000000
> [ 0.026953] x19: 0000000000000030 x18: 0000000000000010
> [ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef
> [ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f
> [ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041
> [ 0.027782] x11: 0000000000000006 x10: 0000000000000042
> [ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c
> [ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84
> [ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000
> [ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f
> [ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035
> [ 0.029056]
> [ 0.029152] ---[ end trace 0000000000000000 ]---
> [ 0.029297] Call trace:
> [ 0.029403] Exception stack(0xffff80003d847b00 to
> 0xffff80003d847c30)
> [ 0.029621] 7b00: 0000000000000030 0001000000000000
> ffff80003d847cd0 ffff00000818e678
> [ 0.029901] 7b20: 0000000000000002 0000000000000004
> ffff000008f7c060 0000000000000035
> [ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88
> ffff80003d847bf0 ffff000008101778
> [ 0.030402] 7b60: 0000000000000030 0000000000000000
> ffff000008e97000 00000000024000c0
> [ 0.030647] 7b80: 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000
> [ 0.030895] 7ba0: 0000000000000035 ffff80003d870000
> 000000000000017f 0000000000000000
> [ 0.031144] 7bc0: 0000000000000000 0000000000000005
> ffff000008f79c84 6120757063726570
> [ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40
> 0000000000000042 0000000000000006
> [ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d
> ffff000088f79c3f 0000000000000006
> [ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f
> [ 0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0
> [ 0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20
> [ 0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4
> [ 0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130
> [ 0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248
> [ 0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100
> [ 0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50
>
> Reported-by: Wei Chen <wei.chen@arm.com>
> Link: https://lkml.org/lkml/2016/11/28/669
> Signed-off-by: Julien Grall <julien.grall@arm.com>
>
> Cc: stable at vger.kernel.org
>
> ---
>
> I have requested backport to stable because the percpu allocator may
> misbehaves when the alignment is not a power of two.
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
I'll fix a small wording issue in the commit message and apply to
xentip.
> arch/arm/xen/enlighten.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index f193414..4986dc0 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -372,8 +372,7 @@ static int __init xen_guest_init(void)
> * for secondary CPUs as they are brought up.
> * For uniformity we use VCPUOP_register_vcpu_info even on cpu0.
> */
> - xen_vcpu_info = __alloc_percpu(sizeof(struct vcpu_info),
> - sizeof(struct vcpu_info));
> + xen_vcpu_info = alloc_percpu(struct vcpu_info);
> if (xen_vcpu_info == NULL)
> return -ENOMEM;
>
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v5 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Anatolij Gustschin @ 2016-12-07 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1778a82d1989d13919b24e47fa09eeb56b2cb8e5.1481139171.git.stillcompiling@gmail.com>
On Wed, 7 Dec 2016 13:04:40 -0800
Joshua Clayton stillcompiling at gmail.com wrote:
...
>+static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
>+ const char *buf, size_t count)
there is a minor API change in linux-next [1]. struct fpga_image_info *
is passed instead of u32 flags. I assume this will be merged soon, so
please prepare this driver accordingly.
...
>+static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
same here.
[1] http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/drivers/fpga?id=1df2865f8dd9d56cb76aa7aa1298921e7bece2af
--
Anatolij
^ permalink raw reply
* [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments
From: Olof Johansson @ 2016-12-07 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8292218.3BDisRkZdU@wuerfel>
On Wed, Dec 7, 2016 at 1:07 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday, December 7, 2016 12:41:29 PM CET Bartlomiej Zolnierkiewicz wrote:
>>
>> On Tuesday, December 06, 2016 11:03:34 AM Olof Johansson wrote:
>> > On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz
>> > <b.zolnierkie@samsung.com> wrote:
>> > > Hi,
>> > >
>> > > This RFC patchset starts convertion of ARM defconfigs to use kconfig
>> > > fragments and dynamically generate defconfigs. The goals of this
>> > > work are to:
>> >
>> > You don't provide any motivation as to why this is better. As far as I
>>
>> Benefits are:
>>
>> - no code duplication (this initial patchset alone removes ~1700 lines
>> from defconfigs without any change in functionality)
>
> This may be interesting
Management of the fragments is the big headache here. I haven't seen
any system that does it well downstream either in a way that scales as
far as we'd need it to.
>> - prevention of "multi" defconfigs (i.e. multi_v7_defconfig) going out
>> of sync with "SoC-family" ones (i.e. exynos_defconfig) - there will
>> be just one place to update when changing things
>
> I'm not convinced this is worthwhile: in a lot of cases, the soc-specific
> configs want to enable things built-in, while the more generic ones
> tend to use loadable modules.
Agreed.
>> - possibility to add support for more optimized defconfigs (i.e. board
>> specific ones) in the future without duplicating the code
>
> I'd prefer seeing fewer top-level options than more of them, so
> this doesn't really help.
>
>> - making it easier to define arch specific parts of defconfigs in
>> the future if we decide on doing it (i.e. we may want to enable
>> things like CONFIG_SYSVIPC for all defconfigs)
>
> The example you give is for something that should be decided
> in architecture-independent Kconfig language rather than
> per architecture, and that won't require fragments.
>
>> > am concerned it'll just be a mess.
>> >
>> > So:
>> >
>> > Nack. So much nack. I really don't want to see a proliferation of
>> > config fragments like this.
>> >
>> > I had a feeling it was a bad idea to pick up that one line config
>> > fragment before, since it opened the door for this kind of mess.
>>
>> Like I said in the cover-letter I'm not satisfied with the current
>> patches and they have much room for improvement.
>>
>> However I see that you don't like the idea itself...
>
> I do think that there is some room for more config fragments in
> mainline, but not most of the patches you have here. Some areas
> that I think would benefit from fragments are:
>
> - architecture level selection: v6/v6k/v7/v7ve/v8 could have a
> common defconfig file that starts out with all v6+ enabled,
> but then having fragments that disable the older architectures
> and platforms using them while turning on features that are only
> available on newer architectures
>
> - A "debug" fragment would be nice, to turn on common options that
> add a lot of useful runtime checks at the expense of performance
> or code size.
Hmm, some of these might work but several useful debug options (in
particular DEBUG_LL for early errors) are per-system/platform.
> - A "distro" fragment that turns on all loadable modules that are
> enabled by common distributions (e.g. two or more of
> debian/fedora/opensuse/gentoo), to let you build a drop-in
> replacement kernel for a shipping distro. This would also allow
> the distros to strip their own config files and just specify
> whatever differs from the others.
Keeping this in sync with the distro kernel could be a bit awkward
(and possibly churny).
-Olof
^ permalink raw reply
* [RFC PATCH 00/23] arm: defconfigs: use kconfig fragments
From: Arnd Bergmann @ 2016-12-07 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4222703.VA8eKM008t@amdc3058>
On Wednesday, December 7, 2016 12:41:29 PM CET Bartlomiej Zolnierkiewicz wrote:
>
> On Tuesday, December 06, 2016 11:03:34 AM Olof Johansson wrote:
> > On Tue, Dec 6, 2016 at 4:38 AM, Bartlomiej Zolnierkiewicz
> > <b.zolnierkie@samsung.com> wrote:
> > > Hi,
> > >
> > > This RFC patchset starts convertion of ARM defconfigs to use kconfig
> > > fragments and dynamically generate defconfigs. The goals of this
> > > work are to:
> >
> > You don't provide any motivation as to why this is better. As far as I
>
> Benefits are:
>
> - no code duplication (this initial patchset alone removes ~1700 lines
> from defconfigs without any change in functionality)
This may be interesting
> - prevention of "multi" defconfigs (i.e. multi_v7_defconfig) going out
> of sync with "SoC-family" ones (i.e. exynos_defconfig) - there will
> be just one place to update when changing things
I'm not convinced this is worthwhile: in a lot of cases, the soc-specific
configs want to enable things built-in, while the more generic ones
tend to use loadable modules.
> - possibility to add support for more optimized defconfigs (i.e. board
> specific ones) in the future without duplicating the code
I'd prefer seeing fewer top-level options than more of them, so
this doesn't really help.
> - making it easier to define arch specific parts of defconfigs in
> the future if we decide on doing it (i.e. we may want to enable
> things like CONFIG_SYSVIPC for all defconfigs)
The example you give is for something that should be decided
in architecture-independent Kconfig language rather than
per architecture, and that won't require fragments.
> > am concerned it'll just be a mess.
> >
> > So:
> >
> > Nack. So much nack. I really don't want to see a proliferation of
> > config fragments like this.
> >
> > I had a feeling it was a bad idea to pick up that one line config
> > fragment before, since it opened the door for this kind of mess.
>
> Like I said in the cover-letter I'm not satisfied with the current
> patches and they have much room for improvement.
>
> However I see that you don't like the idea itself...
I do think that there is some room for more config fragments in
mainline, but not most of the patches you have here. Some areas
that I think would benefit from fragments are:
- architecture level selection: v6/v6k/v7/v7ve/v8 could have a
common defconfig file that starts out with all v6+ enabled,
but then having fragments that disable the older architectures
and platforms using them while turning on features that are only
available on newer architectures
- A "debug" fragment would be nice, to turn on common options that
add a lot of useful runtime checks at the expense of performance
or code size.
- A "distro" fragment that turns on all loadable modules that are
enabled by common distributions (e.g. two or more of
debian/fedora/opensuse/gentoo), to let you build a drop-in
replacement kernel for a shipping distro. This would also allow
the distros to strip their own config files and just specify
whatever differs from the others.
Arnd
^ permalink raw reply
* [PATCH v5 3/3] fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
From: Joshua Clayton @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481139171.git.stillcompiling@gmail.com>
cyclone-ps-spi loads FPGA firmware over spi, using the "passive serial"
interface on Altera Cyclone FPGAS.
This is one of the simpler ways to set up an FPGA at runtime.
The signal interface is close to unidirectional spi with lsb first.
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
drivers/fpga/Kconfig | 7 ++
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 181 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 189 insertions(+)
create mode 100644 drivers/fpga/cyclone-ps-spi.c
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index cd84934..2462707 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -13,6 +13,13 @@ config FPGA
if FPGA
+config FPGA_MGR_CYCLONE_PS_SPI
+ tristate "Altera Cyclone FPGA Passive Serial over SPI"
+ depends on SPI
+ help
+ FPGA manager driver support for Altera Cyclone using the
+ passive serial interface over SPI
+
config FPGA_MGR_SOCFPGA
tristate "Altera SOCFPGA FPGA Manager"
depends on ARCH_SOCFPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 8d83fc6..8f93930 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -6,5 +6,6 @@
obj-$(CONFIG_FPGA) += fpga-mgr.o
# FPGA Manager Drivers
+obj-$(CONFIG_FPGA_MGR_CYCLONE_PS_SPI) += cyclone-ps-spi.o
obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
diff --git a/drivers/fpga/cyclone-ps-spi.c b/drivers/fpga/cyclone-ps-spi.c
new file mode 100644
index 0000000..82a754a
--- /dev/null
+++ b/drivers/fpga/cyclone-ps-spi.c
@@ -0,0 +1,181 @@
+/**
+ * Copyright (c) 2015 United Western Technologies, Corporation
+ *
+ * Joshua Clayton <stillcompiling@gmail.com>
+ *
+ * Manage Altera fpga firmware that is loaded over spi.
+ * Firmware must be in binary "rbf" format.
+ * Works on Cyclone V. Should work on cyclone series.
+ * May work on other Altera fpgas.
+ *
+ */
+
+#include <linux/bitrev.h>
+#include <linux/delay.h>
+#include <linux/fpga/fpga-mgr.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of_gpio.h>
+#include <linux/spi/spi.h>
+#include <linux/sizes.h>
+
+#define FPGA_RESET_TIME 50 /* time in usecs to trigger FPGA config */
+#define FPGA_MIN_DELAY 50 /* min usecs to wait for config status */
+#define FPGA_MAX_DELAY 1000 /* max usecs to wait for config status */
+
+struct cyclonespi_conf {
+ struct gpio_desc *config;
+ struct gpio_desc *status;
+ struct spi_device *spi;
+};
+
+static const struct of_device_id of_ef_match[] = {
+ { .compatible = "altr,cyclone-ps-spi-fpga-mgr", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, of_ef_match);
+
+static enum fpga_mgr_states cyclonespi_state(struct fpga_manager *mgr)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status))
+ return FPGA_MGR_STATE_RESET;
+
+ return FPGA_MGR_STATE_UNKNOWN;
+}
+
+static int cyclonespi_write_init(struct fpga_manager *mgr, u32 flags,
+ const char *buf, size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ int i;
+
+ if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
+ dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
+ return -EINVAL;
+ }
+
+ gpiod_set_value(conf->config, 1);
+ usleep_range(FPGA_RESET_TIME, FPGA_RESET_TIME + 20);
+ if (!gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Status pin should be low.\n");
+ return -EIO;
+ }
+
+ gpiod_set_value(conf->config, 0);
+ for (i = 0; i < (FPGA_MAX_DELAY / FPGA_MIN_DELAY); i++) {
+ usleep_range(FPGA_MIN_DELAY, FPGA_MIN_DELAY + 20);
+ if (!gpiod_get_value(conf->status))
+ return 0;
+ }
+
+ dev_err(&mgr->dev, "Status pin not ready.\n");
+ return -EIO;
+}
+
+static void rev_buf(void *buf, size_t len)
+{
+ u32 *fw32 = (u32 *)buf;
+ const u32 *fw_end = (u32 *)(buf + len);
+
+ /* set buffer to lsb first */
+ while (fw32 < fw_end) {
+ *fw32 = bitrev8x4(*fw32);
+ fw32++;
+ }
+}
+
+static int cyclonespi_write(struct fpga_manager *mgr, const char *buf,
+ size_t count)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+ const char *fw_data = buf;
+ const char *fw_data_end = fw_data + count;
+
+ while (fw_data < fw_data_end) {
+ int ret;
+ size_t stride = min(fw_data_end - fw_data, SZ_4K);
+
+ rev_buf((void *)fw_data, stride);
+ ret = spi_write(conf->spi, fw_data, stride);
+ if (ret) {
+ dev_err(&mgr->dev, "spi error in firmware write: %d\n",
+ ret);
+ return ret;
+ }
+ fw_data += stride;
+ }
+
+ return 0;
+}
+
+static int cyclonespi_write_complete(struct fpga_manager *mgr, u32 flags)
+{
+ struct cyclonespi_conf *conf = (struct cyclonespi_conf *)mgr->priv;
+
+ if (gpiod_get_value(conf->status)) {
+ dev_err(&mgr->dev, "Error during configuration.\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static const struct fpga_manager_ops cyclonespi_ops = {
+ .state = cyclonespi_state,
+ .write_init = cyclonespi_write_init,
+ .write = cyclonespi_write,
+ .write_complete = cyclonespi_write_complete,
+};
+
+static int cyclonespi_probe(struct spi_device *spi)
+{
+ struct cyclonespi_conf *conf = devm_kzalloc(&spi->dev, sizeof(*conf),
+ GFP_KERNEL);
+
+ if (!conf)
+ return -ENOMEM;
+
+ conf->spi = spi;
+ conf->config = devm_gpiod_get(&spi->dev, "config", GPIOD_OUT_HIGH);
+ if (IS_ERR(conf->config)) {
+ dev_err(&spi->dev, "Failed to get config gpio: %ld\n",
+ PTR_ERR(conf->config));
+ return PTR_ERR(conf->config);
+ }
+
+ conf->status = devm_gpiod_get(&spi->dev, "status", GPIOD_IN);
+ if (IS_ERR(conf->status)) {
+ dev_err(&spi->dev, "Failed to get status gpio: %ld\n",
+ PTR_ERR(conf->status));
+ return PTR_ERR(conf->status);
+ }
+
+ return fpga_mgr_register(&spi->dev,
+ "Altera Cyclone PS SPI FPGA Manager",
+ &cyclonespi_ops, conf);
+}
+
+static int cyclonespi_remove(struct spi_device *spi)
+{
+ fpga_mgr_unregister(&spi->dev);
+
+ return 0;
+}
+
+static struct spi_driver cyclonespi_driver = {
+ .driver = {
+ .name = "cyclone-ps-spi",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(of_ef_match),
+ },
+ .probe = cyclonespi_probe,
+ .remove = cyclonespi_remove,
+};
+
+module_spi_driver(cyclonespi_driver)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Joshua Clayton <stillcompiling@gmail.com>");
+MODULE_DESCRIPTION("Module to load Altera FPGA firmware over spi");
--
2.9.3
^ permalink raw reply related
* [PATCH v5 2/3] doc: dt: add cyclone-ps-spi binding document
From: Joshua Clayton @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481139171.git.stillcompiling@gmail.com>
Describe a cyclone-ps-spi devicetree entry, required features
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 ++++++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
diff --git a/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
new file mode 100644
index 0000000..3f515c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
@@ -0,0 +1,25 @@
+Altera Cyclone Passive Serial SPI FPGA Manager
+
+Altera Cyclone FPGAs support a method of loading the bitstream over what is
+referred to as "passive serial".
+The passive serial link is not technically spi, and might require extra
+circuits in order to play nicely with other spi slaves on the same bus.
+
+See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
+
+Required properties:
+- compatible : should contain "altr,cyclone-ps-spi-fpga-mgr"
+- reg : spi slave id of the fpga
+- config-gpios : config pin (referred to as nCONFIG in the cyclone manual)
+- status-gpios : status pin (referred to as nSTATUS in the cyclone manual)
+
+both gpios pins are normally active low open drain.
+
+Example:
+ fpga_spi: evi-fpga-spi at 0 {
+ compatible = "altr,cyclone-ps-spi-fpga-mgr";
+ spi-max-frequency = <20000000>;
+ reg = <0>;
+ config-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>;
+ status-gpios = <&gpio4 11 GPIO_ACTIVE_LOW>;
+ };
--
2.9.3
^ permalink raw reply related
* [PATCH v5 1/3] lib: add bitrev8x4()
From: Joshua Clayton @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1481139171.git.stillcompiling@gmail.com>
Add a function to reverse bytes within a 32 bit word.
This function is more efficient than using the 8 bit version when
iterating over an array
Signed-off-by: Joshua Clayton <stillcompiling@gmail.com>
---
arch/arm/include/asm/bitrev.h | 6 ++++++
include/linux/bitrev.h | 26 ++++++++++++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/include/asm/bitrev.h b/arch/arm/include/asm/bitrev.h
index ec291c3..9482f78 100644
--- a/arch/arm/include/asm/bitrev.h
+++ b/arch/arm/include/asm/bitrev.h
@@ -17,4 +17,10 @@ static __always_inline __attribute_const__ u8 __arch_bitrev8(u8 x)
return __arch_bitrev32((u32)x) >> 24;
}
+static __always_inline __attribute_const__ u32 __arch_bitrev8x4(u32 x)
+{
+ __asm__ ("rbit %0, %1; rev %0, %0" : "=r" (x) : "r" (x));
+ return x;
+}
+
#endif
diff --git a/include/linux/bitrev.h b/include/linux/bitrev.h
index fb790b8..b1cfa1a 100644
--- a/include/linux/bitrev.h
+++ b/include/linux/bitrev.h
@@ -9,6 +9,7 @@
#define __bitrev32 __arch_bitrev32
#define __bitrev16 __arch_bitrev16
#define __bitrev8 __arch_bitrev8
+#define __bitrev8x4 __arch_bitrev8x4
#else
extern u8 const byte_rev_table[256];
@@ -27,6 +28,14 @@ static inline u32 __bitrev32(u32 x)
return (__bitrev16(x & 0xffff) << 16) | __bitrev16(x >> 16);
}
+static inline u32 __bitrev8x4(u32 x)
+{
+ return(__bitrev8(x & 0xff) |
+ (__bitrev8((x >> 8) & 0xff) << 8) |
+ (__bitrev8((x >> 16) & 0xff) << 16) |
+ (__bitrev8((x >> 24) & 0xff) << 24));
+}
+
#endif /* CONFIG_HAVE_ARCH_BITREVERSE */
#define __constant_bitrev32(x) \
@@ -50,6 +59,15 @@ static inline u32 __bitrev32(u32 x)
__x; \
})
+#define __constant_bitrev8x4(x) \
+({ \
+ u32 __x = x; \
+ __x = ((__x & (u32)0xF0F0F0F0UL) >> 4) | ((__x & (u32)0x0F0F0F0FUL) << 4); \
+ __x = ((__x & (u32)0xCCCCCCCCUL) >> 2) | ((__x & (u32)0x33333333UL) << 2); \
+ __x = ((__x & (u32)0xAAAAAAAAUL) >> 1) | ((__x & (u32)0x55555555UL) << 1); \
+ __x; \
+})
+
#define __constant_bitrev8(x) \
({ \
u8 __x = x; \
@@ -75,6 +93,14 @@ static inline u32 __bitrev32(u32 x)
__bitrev16(__x); \
})
+#define bitrev8x4(x) \
+({ \
+ u32 __x = x; \
+ __builtin_constant_p(__x) ? \
+ __constant_bitrev8x4(__x) : \
+ __bitrev8x4(__x); \
+})
+
#define bitrev8(x) \
({ \
u8 __x = x; \
--
2.9.3
^ permalink raw reply related
* [PATCH v5 0/3] Altera Cyclone Passive Serial SPI FPGA Manager
From: Joshua Clayton @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
This series adds an FPGA manager for Altera cyclone FPGAs
that can program them using an spi port and a couple of gpios, using
Alteras passive serial protocol.
Still need an ACK from Russell King on the ARM specific portion of
patch 1. Any comment/criticism on the addition of bitrev8x4() to bitrev.h
would be welcome as well.
Changes from v4:
- Added the needed return statement to __arch_bitrev8x4()
- Added Rob Herrings ACK for and fix a typo in the commit log of patch 2
Changes from v3:
- Fixed up the state() function to return the state of the status pin
reqested by Alan Tull
- Switched the pin to ACTIVE_LOW and coresponding logic level, and updated
the corresponding documentation. Thanks Rob Herring for pointing out my
mistake.
- Per Rob Herring, switched from "gpio" to "gpios" in dts
Changes from v2:
- Merged patch 3 and 4 as suggested in review by Moritz Fischer
- Changed FPGA_MIN_DELAY from 250 to 50 ms is the time advertized by
Altera. This now works, as we don't assume it is done
Changes from v1:
- Changed the name from cyclone-spi-fpga-mgr to cyclone-ps-spi-fpga-mgr
This name change was requested by Alan Tull, to be specific about which
programming method is being employed on the fpga.
- Changed the name of the reset-gpio to config-gpio to closer match the
way the pins are described in the Altera manual
- Moved MODULE_LICENCE, _AUTHOR, and _DESCRIPTION to the bottom
- Added a bitrev8x4() function to the bitrev headers and implemented ARM
const, runtime, and ARM specific faster versions (This may end up
needing to be a standalone patch)
- Moved the bitswapping into cyclonespi_write(), as requested.
This falls short of my desired generic lsb first spi support, but is a step
in that direction.
- Fixed whitespace problems introduced during refactoring
- Replaced magic number for initial delay with a descriptive macro
- Poll the fpga to see when it is ready rather than a fixed 1 ms sleep
Joshua Clayton (3):
lib: add bitrev8x4()
doc: dt: add cyclone-ps-spi binding document
fpga manager: Add cyclone-ps-spi driver for Altera FPGAs
.../bindings/fpga/cyclone-ps-spi-fpga-mgr.txt | 25 +++
arch/arm/include/asm/bitrev.h | 6 +
drivers/fpga/Kconfig | 7 +
drivers/fpga/Makefile | 1 +
drivers/fpga/cyclone-ps-spi.c | 181 +++++++++++++++++++++
include/linux/bitrev.h | 26 +++
6 files changed, 246 insertions(+)
create mode 100644 Documentation/devicetree/bindings/fpga/cyclone-ps-spi-fpga-mgr.txt
create mode 100644 drivers/fpga/cyclone-ps-spi.c
--
2.9.3
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-07 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207193908.GA13062@netboy>
On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > +static s32 gem_ptp_max_adj(unsigned int f_nom)
> > +{
> > + u64 adj;
> > +
> > + /* The 48 bits of seconds for the GEM overflows every:
> > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > + * thus the maximum adjust frequency must not overflow CNS register:
> > + *
> > + * addend = 10^9/nominal_freq
> > + * adj_max = +/- addend*ppb_max/10^9
> > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > + */
> > + adj = f_nom;
> > + adj *= 0xffff;
> > + adj -= 1000000000ULL;
>
> What is this computation, and how does it relate to the comment?
I am not sure what you meant, but it sounds like you are on the wrong
track. Let me explain...
The max_adj has nothing at all to do with the width of the time
register. Rather, it should reflect the maximum possible change in
the tuning word.
For example, with a nominal 8 ns period, the tuning word is 0x80000.
Looking at running the clock more slowly, the slowest possible word is
0x00001, meaning a difference of 0x7FFFF. This implies an adjustment
of 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
already have 0x100000, twice as fast, or just under 2 billion ppb.
You should consider the extreme cases to determine the most limited
(smallest) max_adj value:
Case 1 - high frequency
~~~~~~~~~~~~~~~~~~~~~~~
With a nominal 1 ns period, we have the nominal tuning word 0x10000.
The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
Case 2 - low frequency
~~~~~~~~~~~~~~~~~~~~~~
With a nominal 255 ns period, the nominal word is 0xFF0000, the
largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
Since 3921508 ppb is a huge adjustment, you can simply use that as a
safe maximum, ignoring the actual input clock.
Thanks,
Richard
^ permalink raw reply
* [PATCH] ARM: dts: imx7d: fix LCDIF clock assignment
From: Olof Johansson @ 2016-12-07 20:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205020123.GA2066@dragon>
On Mon, Dec 05, 2016 at 10:01:24AM +0800, Shawn Guo wrote:
> Hi Arnd, Olof,
>
> On Sun, Dec 04, 2016 at 05:26:58PM -0800, Stefan Agner wrote:
> > Hi Shawn
> >
> > On 2016-11-23 15:02, Fabio Estevam wrote:
> > > On Tue, Nov 22, 2016 at 10:42 PM, Stefan Agner <stefan@agner.ch> wrote:
> > >> The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them
> > >> separately:
> > >>
> > >> Clock Clock Root Description
> > >> apb_clk MAIN_AXI_CLK_ROOT AXI clock
> > >> pix_clk LCDIF_PIXEL_CLK_ROOT Pixel clock
> > >> ipg_clk_s MAIN_AXI_CLK_ROOT Peripheral access clock
> > >>
> > >> All of them are switched by a single gate, which is part of the
> > >> IMX7D_LCDIF_PIXEL_ROOT_CLK clock. Hence using that clock also for
> > >> the AXI bus clock (clock-name "axi") makes sure the gate gets
> > >> enabled when accessing registers.
> > >>
> > >> There seem to be no separate AXI display clock, and the clock is
> > >> optional. Hence remove the dummy clock.
> > >>
> > >> This fixes kernel freezes when starting the X-Server (which
> > >> disables/re-enables the display controller).
> > >>
> > >> Signed-off-by: Stefan Agner <stefan@agner.ch>
> > >
> > > Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
> >
> > Since this fixes a kernel freeze, is there a chance to get this still in
> > 4.9?
>
> Since we get one more week to the final 4.9, is it possible for you to
> send this fix for 4.9 inclusion? Thanks.
>
> For the patch,
>
> Acked-by: Shawn Guo <shawnguo@kernel.org>
Applied, with the fixes line. In the future, please email arm at kernel.org too,
it's easier to make sure we don't miss it that way.
-Olof
^ permalink raw reply
* [PATCH] dts: sun8i-h3: correct UART3 pin definitions
From: Olof Johansson @ 2016-12-07 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206142710.6450-1-jorik@kippendief.biz>
On Tue, Dec 06, 2016 at 03:27:10PM +0100, jorik at kippendief.biz wrote:
> From: Jorik Jonker <jorik@kippendief.biz>
>
> In a previous commit, I made a copy/paste error in the pinmux
> definitions of UART3: PG{13,14} instead of PA{13,14}. This commit takes
> care of that. I have tested this commit on Orange Pi PC and Orange Pi
> Plus, and it works for these boards.
>
> Fixes: e3d11d3c45c5 ("dts: sun8i-h3: add pinmux definitions for
> UART2-3")
>
> Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Applied to fixes. Thanks.
-Olof
^ permalink raw reply
* [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
From: Arnd Bergmann @ 2016-12-07 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207165913.GD31779@e104818-lin.cambridge.arm.com>
On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:
> > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > detection of the task type.
> > >
> > > What's wrong with the run-time detection? If it's just to avoid a
> > > negligible overhead, I would rather keep the code simpler by avoiding
> > > duplicating the generic compat_sys_ptrace().
> >
> > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
>
> Hmm, I completely forgot about this ;). There is still an advantage to
> doing run-time checking if we avoid touching core code (less acks to
> gather and less code duplication).
>
> Let's see what Arnd says but the initial patch looked simpler.
I don't currently have either version of the patch in my inbox
(the archive is on a different machine), but in general I'd still
think it's best to avoid the runtime check for aarch64-ilp32
altogether. I'd have to look at the overall kernel source to
see if it's worth avoiding one or two instances though, or
if there are an overwhelming number of other checks that we
can't avoid at all.
Regarding ptrace, I notice that arch/tile doesn't even use
the compat entry point for its ilp32 user space on 64-bit
kernels, it just calls the regular 64-bit one. Would that
help here?
Arnd
^ permalink raw reply
* [GIT PULL v2] ARM: Xilinx Zynq DT changes for v4.10
From: Olof Johansson @ 2016-12-07 20:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <78b672c5-2f17-f166-815f-47b05dba66e7@monstr.eu>
On Tue, Dec 06, 2016 at 01:51:45PM +0100, Michal Simek wrote:
> Hi,
>
> please add these changes to your arm-soc repo.
> It fixes dtc warnings, small coding style changes and add support for
> Microzed.
>
> Thanks,
> Michal
>
> ---
> v2: Use correct zynq-dt-for-4.10 tag instead of zynqmp-dt-for-4.10.
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/Xilinx/linux-xlnx.git tags/zynq-dt-for-4.10
>
> for you to fetch changes up to df2f3c48b9cd51e2612a1598342769d09d849f39:
>
> arm: dts: zynq: Add MicroZed board support (2016-12-06 13:17:39 +0100)
Merged. In the future it'd be nice to get these a few weeks earlier in the
cycle.
-Olof
^ permalink raw reply
* [GIT PULL] ARM: Xilinx Zynq SOC changes for v4.10
From: Olof Johansson @ 2016-12-07 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1ff060ae-b142-9e72-6fef-21b81a147614@monstr.eu>
On Tue, Dec 06, 2016 at 01:46:01PM +0100, Michal Simek wrote:
> Hi,
>
> please pull this fix to your tree.
>
> Thanks,
> Michal
>
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> https://github.com/Xilinx/linux-xlnx.git tags/zynq-soc-for-4.10
>
> for you to fetch changes up to 7a3cc2a7b2c723aa552028f4e66841cec183756d:
>
> ARM: zynq: Reserve correct amount of non-DMA RAM (2016-11-14 16:07:58
> +0100)
>
> ----------------------------------------------------------------
> arm: Xilinx Zynq patches for v4.10
>
> - Fix dma issue
>
> ----------------------------------------------------------------
> Kyle Roeschley (1):
> ARM: zynq: Reserve correct amount of non-DMA RAM
Merged, thanks. Should this have been a fix, btw? I queued it for 4.10 merge
window now.
-Olof
^ permalink raw reply
* [GIT PULL 2/2] DaVinci defconfig updates for v4.10 (part 4)
From: Olof Johansson @ 2016-12-07 20:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205110316.18514-2-nsekhar@ti.com>
On Mon, Dec 05, 2016 at 04:33:16PM +0530, Sekhar Nori wrote:
> The following changes since commit 213971e7571e27f47b4e926904a9adf794925c51:
>
> ARM: davinci_all_defconfig: Enable OHCI as module (2016-11-22 20:50:46 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/defconfig-4
>
> for you to fetch changes up to 47d03e48efa572109229aec9436948d92f44b689:
>
> ARM: davinci_all_defconfig: Enable da8xx usb otg (2016-12-01 19:52:12 +0530)
>
> ----------------------------------------------------------------
> Enable support for MUSB based USB OTG on DA850.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/2] DaVinci DT updates for v4.10 (part 4)
From: Olof Johansson @ 2016-12-07 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205110316.18514-1-nsekhar@ti.com>
On Mon, Dec 05, 2016 at 04:33:15PM +0530, Sekhar Nori wrote:
> The following changes since commit 878e908ad95637dc6567a9b5f6876a580ae90dfa:
>
> ARM: dts: da850: enable memctrl and mstpri nodes per board (2016-11-28 15:51:29 +0530)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/dt-4
>
> for you to fetch changes up to e4ce904d6289f2a72affd2a0f0a44da6e5d0cce4:
>
> ARM: dts: da850: enable high speed for mmc (2016-12-05 14:20:44 +0530)
>
> ----------------------------------------------------------------
> - Add device tree nodes for pin pull-up/pull-down
> bias control on DA850.
>
> - Enable high speed support on DA850 MMC/SD
Merged, thanks. It's getting late but this is a small delta.
-Olof
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Olof Johansson @ 2016-12-07 20:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206011244.GC2749@dragon>
On Tue, Dec 06, 2016 at 09:12:46AM +0800, Shawn Guo wrote:
> Hi Olof,
>
> On Mon, Dec 05, 2016 at 04:55:02PM -0800, Olof Johansson wrote:
> > Hi Shawn,
> >
> > On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> > > Hi Arnd,
> > >
> > > On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
> > >> Given that there is any concern about the patch now, and the merge
> > >> window is almost open, I'm moving both patches to the
> > >> next/fixes-non-critical branch and will merge it for v4.10 instead
> > >> of sending it for v4.9.
> > >>
> > >> If you end up deciding that the patch is wrong, please follow up
> > >> with a fix on top. Once the situation is resolved and the patch
> > >> merged upstream, feel free to ask stable at vger.kernel.org for a
> > >> backport to stable kernels to get it into v4.9.x.
> > >
> > > The patch is correct, though it can be cleaned up a bit further per
> > > Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can
> > > still get this into 4.9 to save the stable kernel backport.
> > >
> > > I sent you a cleanup patch on top of this one yesterday. If you like,
> > > I can quickly resend the patch with the cleanup squashed.
> >
> > Since the patches have already been applied, an incremental patch to
> > apply on top would work best here.
>
> No problem. So would you please apply the incremental patch [1] to the
> same branch? Or I can send it to you later during -rc cycles. Just let
> me know your preference.
>
> Shawn
>
> [1] https://www.spinics.net/lists/arm-kernel/msg546957.html
So, it seems that Arnd didn't apply the old patch to fixes-non-critical, or
at least didn't push out after doing it. So, I've done that now, as well as
applied the fixup you have above.
-Olof
^ permalink raw reply
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Eric Biggers @ 2016-12-07 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_HUjCparJnZXzZR=m3obt+aypibpHrP_ivA==1QNYksg@mail.gmail.com>
On Wed, Dec 07, 2016 at 07:53:51PM +0000, Ard Biesheuvel wrote:
> Does this help at all?
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 670893bcf361..59e67f5b544b 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -63,7 +63,7 @@ int alg_test(const char *driver, const char *alg,
> u32 type, u32 mask)
> */
> #define IDX1 32
> #define IDX2 32400
> -#define IDX3 511
> +#define IDX3 1511
> #define IDX4 8193
> #define IDX5 22222
> #define IDX6 17101
>
Yes, with that change made the self-tests pass.
Eric
^ permalink raw reply
* Synopsys Ethernet QoS Driver
From: Andy Shevchenko @ 2016-12-07 20:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87c8a24b-0812-7850-cb3f-7be691bab432@st.com>
On Mon, Nov 21, 2016 at 2:52 PM, Giuseppe CAVALLARO
<peppe.cavallaro@st.com> wrote:
First of all, +1 to (re-)use stmmac.
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.
As Intel employee who did some clean ups to that, acknowledge above.
> Concerning the stmicro/stmmac naming, these come from a really old
> story and have no issue to adopt new folder/file names.
I don't think it would be best idea for platform driver (though we can
keep driver's name in the structure in async with file name).
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k
From: Ilia Mirkin @ 2016-12-07 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAVeFuKfo3sZL84wTiR6ur=PVsPhcaU62ggTwy9r1aQEOq2HZw@mail.gmail.com>
On Wed, Dec 7, 2016 at 4:57 AM, Alexandre Courbot <gnurou@gmail.com> wrote:
> On Wed, Dec 7, 2016 at 6:53 PM, Michel D?nzer <michel@daenzer.net> wrote:
>> On 07/12/16 06:39 PM, Alexandre Courbot wrote:
>>> On Fri, Dec 2, 2016 at 12:23 PM, Ilia Mirkin <imirkin@alum.mit.edu> wrote:
>>>> That's right -- nouveau currently requires 4k page sizes to work. This is a
>>>> software limitation, not a hardware one though.
>>>
>>> Looking at the trace I wonder - is the limitation in Nouveau or in TTM?
>>
>> Nouveau. Non-4K page sizes work fine with radeon (and presumably amdgpu).
>
> Thanks for the precision. I will check if Tegra iGPUs are also
> affected by this - if they are then it gives me a good excuse to take
> care of this bug.
For the most part it's confusion in the (nouveau) code as to what's a
gpu page and what's a cpu page (and the shifts involved). There are
some fringe issues that will need to be addressed, like the fact that
it's no longer a 1:1 mapping, which might be assumed in some places.
However I thought that 64K-pages were frowned upon nowadays for the
kernel - outside of HPC loads, most of the kernel memory becomes
pagecache, and files don't tend to be 64K-sized, so you have tons of
wasted memory (since you never cache multiple files in the same page).
But don't take that as me disapproving of such a project. It'd esp be
nice to do something like this outside of the PPC64 environment, where
BE concerns mix in with the 64K page concerns, and nothing works as a
result.
-ilia
^ permalink raw reply
* [PATCH] arm64: Work around Falkor erratum 1009
From: Christopher Covington @ 2016-12-07 20:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207200028.4420-1-cov@codeaurora.org>
From: Shanker Donthineni <shankerd@codeaurora.org>
During a TLB invalidate sequence targeting the inner shareable
domain, Falkor may prematurely complete the DSB before all loads
and stores using the old translation are observed; instruction
fetches are not subject to the conditions of this erratum.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/Kconfig | 10 +++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/tlbflush.h | 43 +++++++++++++++++++++++++++++++++++++++
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/kvm/hyp/tlb.c | 39 ++++++++++++++++++++++++++++++-----
5 files changed, 96 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 1004a3d..125440f 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -485,6 +485,16 @@ config QCOM_FALKOR_ERRATUM_E1003
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1009
+ bool "Falkor E1009: Prematurely complete a DSB after a TLBI"
+ default y
+ help
+ Falkor CPU may prematurely complete a DSB following a TLBI xxIS
+ invalidate maintenance operations. Repeat the TLBI operation one
+ more time to fix the issue.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index cb6a8c2..5357d7f 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -35,7 +35,8 @@
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 16
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1009 17
-#define ARM64_NCAPS 17
+#define ARM64_NCAPS 18
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/tlbflush.h b/arch/arm64/include/asm/tlbflush.h
index deab523..03bafc5 100644
--- a/arch/arm64/include/asm/tlbflush.h
+++ b/arch/arm64/include/asm/tlbflush.h
@@ -23,6 +23,7 @@
#include <linux/sched.h>
#include <asm/cputype.h>
+#include <asm/alternative.h>
/*
* Raw TLBI operations.
@@ -94,6 +95,13 @@ static inline void flush_tlb_all(void)
dsb(ishst);
__tlbi(vmalle1is);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vmalle1is \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : :);
isb();
}
@@ -104,6 +112,13 @@ static inline void flush_tlb_mm(struct mm_struct *mm)
dsb(ishst);
__tlbi(aside1is, asid);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi aside1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (asid));
}
static inline void flush_tlb_page(struct vm_area_struct *vma,
@@ -114,6 +129,13 @@ static inline void flush_tlb_page(struct vm_area_struct *vma,
dsb(ishst);
__tlbi(vale1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vale1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (addr));
}
/*
@@ -145,6 +167,13 @@ static inline void __flush_tlb_range(struct vm_area_struct *vma,
__tlbi(vae1is, addr);
}
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (end));
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
@@ -169,6 +198,13 @@ static inline void flush_tlb_kernel_range(unsigned long start, unsigned long end
for (addr = start; addr < end; addr += 1 << (PAGE_SHIFT - 12))
__tlbi(vaae1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vaae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (end));
isb();
}
@@ -183,6 +219,13 @@ static inline void __flush_tlb_pgtable(struct mm_struct *mm,
__tlbi(vae1is, addr);
dsb(ish);
+ asm volatile(ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "tlbi vae1is, %0 \n"
+ "dsb ish \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (addr));
}
#endif
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 3789e2f..8013579 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -137,6 +137,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
},
#endif
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1009
+ {
+ .desc = "Qualcomm Falkor erratum E1009",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1009,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/kvm/hyp/tlb.c b/arch/arm64/kvm/hyp/tlb.c
index 88e2f2b..dfd3a77 100644
--- a/arch/arm64/kvm/hyp/tlb.c
+++ b/arch/arm64/kvm/hyp/tlb.c
@@ -16,6 +16,7 @@
*/
#include <asm/kvm_hyp.h>
+#include <asm/alternative.h>
void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
{
@@ -32,7 +33,14 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* whole of Stage-1. Weep...
*/
ipa >>= 12;
- asm volatile("tlbi ipas2e1is, %0" : : "r" (ipa));
+ asm volatile("tlbi ipas2e1is, %0 \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi ipas2e1is, %0 \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : "r" (ipa));
/*
* We have to ensure completion of the invalidation at Stage-2,
@@ -41,7 +49,14 @@ void __hyp_text __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
* the Stage-1 invalidation happened first.
*/
dsb(ish);
- asm volatile("tlbi vmalle1is" : : );
+ asm volatile("tlbi vmalle1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi vmalle1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : );
dsb(ish);
isb();
@@ -57,7 +72,14 @@ void __hyp_text __kvm_tlb_flush_vmid(struct kvm *kvm)
write_sysreg(kvm->arch.vttbr, vttbr_el2);
isb();
- asm volatile("tlbi vmalls12e1is" : : );
+ asm volatile("tlbi vmalls12e1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi vmalls12e1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ : : );
dsb(ish);
isb();
@@ -82,7 +104,14 @@ void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu *vcpu)
void __hyp_text __kvm_flush_vm_context(void)
{
dsb(ishst);
- asm volatile("tlbi alle1is \n"
- "ic ialluis ": : );
+ asm volatile("tlbi alle1is \n"
+ ALTERNATIVE(
+ "nop \n"
+ "nop \n",
+ "dsb ish \n"
+ "tlbi alle1is \n",
+ ARM64_WORKAROUND_QCOM_FALKOR_E1009)
+ "ic ialluis \n"
+ : : );
dsb(ish);
}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v6 0/5] davinci: VPIF: add DT support
From: Javier Martinez Canillas @ 2016-12-07 20:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-1-khilman@baylibre.com>
Hello Kevin,
On Wed, Dec 7, 2016 at 3:30 PM, Kevin Hilman <khilman@baylibre.com> wrote:
> Prepare the groundwork for adding DT support for davinci VPIF drivers.
> This series does some fixups/cleanups and then adds the DT binding and
> DT compatible string matching for DT probing.
>
> The controversial part from previous versions around async subdev
> parsing, and specifically hard-coding the input/output routing of
> subdevs, has been left out of this series. That part can be done as a
> follow-on step after agreement has been reached on the path forward.
I had a similar need for another board (OMAP3 IGEPv2), that has a
TVP5151 video decoder (that also supports 2 composite or 1 s-video
signal) attached to the OMAP3 ISP.
I posted some RFC patches [0] to define the input signals in the DT,
and AFAICT Laurent and Hans were not against the approach but just had
some comments on the DT binding.
Basically they wanted the ports to be directly in the tvp5150 node
instead of under a connectors sub-node [1] and to just be called just
a (input / output) port instead of a connector [2].
Unfortunately I was busy with other tasks so I couldn't res-pin the
patches, but I think you could have something similar in the DT
binding for your case and it shouldn't be hard to parse the ports /
endpoints in the driver to get that information from DT and setup the
input and output pins.
> With this version, platforms can still use the VPIF capture/display
> drivers, but must provide platform_data for the subdevs and subdev
> routing.
>
I guess DT backward compatibility isn't a big issue on this platform,
since support for the platform is quite recently and after all someone
who wants to use the vpif with current DT will need platform data and
pdata-quirks anyways. So I agree with you that the input / output
signals lookup from DT could be done as a follow-up.
[0]: https://lkml.org/lkml/2016/4/12/983
[1]: https://lkml.org/lkml/2016/4/27/678
[2]: https://lkml.org/lkml/2016/11/11/346
Best regards,
Javier
^ permalink raw reply
* [PATCH 2/3] arm64: Work around Falkor erratum 1003
From: Christopher Covington @ 2016-12-07 20:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207200028.4420-1-cov@codeaurora.org>
From: Shanker Donthineni <shankerd@codeaurora.org>
On the Qualcomm Datacenter Technologies Falkor v1 CPU, memory accesses may
allocate TLB entries using an incorrect ASID when TTBRx_EL1 is being
updated. Changing the TTBRx_EL1[ASID] and TTBRx_EL1[BADDR] fields
separately using a reserved ASID will ensure that there are no TLB entries
with incorrect ASID after changing the the ASID.
Pseudo code:
write TTBRx_EL1[ASID] to a reserved value
ISB
write TTBRx_EL1[BADDR] to a desired value
ISB
write TTBRx_EL1[ASID] to a desired value
ISB
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/Kconfig | 11 +++++++++++
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpu_errata.c | 7 +++++++
arch/arm64/mm/context.c | 10 ++++++++++
arch/arm64/mm/proc.S | 21 +++++++++++++++++++++
5 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 969ef88..1004a3d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -474,6 +474,17 @@ config CAVIUM_ERRATUM_27456
If unsure, say Y.
+config QCOM_FALKOR_ERRATUM_E1003
+ bool "Falkor E1003: Incorrect translation due to ASID change"
+ default y
+ help
+ An incorrect translation TLBI entry may be created while
+ changing the ASID & translation table address together for
+ TTBR0_EL1. The workaround for this issue is use a reserved
+ ASID in cpu_do_switch_mm() before switching to target ASID.
+
+ If unsure, say Y.
+
endmenu
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 87b4465..cb6a8c2 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -34,7 +34,8 @@
#define ARM64_HAS_32BIT_EL0 13
#define ARM64_HYP_OFFSET_LOW 14
#define ARM64_MISMATCHED_CACHE_LINE_SIZE 15
+#define ARM64_WORKAROUND_QCOM_FALKOR_E1003 16
-#define ARM64_NCAPS 16
+#define ARM64_NCAPS 17
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b75e917..3789e2f 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -130,6 +130,13 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
.def_scope = SCOPE_LOCAL_CPU,
.enable = cpu_enable_trap_ctr_access,
},
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1003
+ {
+ .desc = "Qualcomm Falkor erratum E1003",
+ .capability = ARM64_WORKAROUND_QCOM_FALKOR_E1003,
+ MIDR_RANGE(MIDR_QCOM_FALKOR_V1, 0x00, 0x00),
+ },
+#endif
{
}
};
diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index efcf1f7..f8d94ff 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -87,6 +87,11 @@ static void flush_context(unsigned int cpu)
/* Update the list of reserved ASIDs and the ASID bitmap. */
bitmap_clear(asid_map, 0, NUM_USER_ASIDS);
+ /* Reserve ASID '1' for Falkor erratum E1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_E1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(1, asid_map);
+
/*
* Ensure the generation bump is observed before we xchg the
* active_asids.
@@ -239,6 +244,11 @@ static int asids_init(void)
panic("Failed to allocate bitmap for %lu ASIDs\n",
NUM_USER_ASIDS);
+ /* Reserve ASID '1' for Falkor erratum E1003 */
+ if (IS_ENABLED(CONFIG_QCOM_FALKOR_ERRATUM_E1003) &&
+ cpus_have_cap(ARM64_WORKAROUND_QCOM_FALKOR_E1003))
+ __set_bit(1, asid_map);
+
pr_info("ASID allocator initialised with %lu entries\n", NUM_USER_ASIDS);
return 0;
}
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 352c73b..b4d6508 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -134,6 +134,27 @@ ENDPROC(cpu_do_resume)
ENTRY(cpu_do_switch_mm)
mmid x1, x1 // get mm->context.id
bfi x0, x1, #48, #16 // set the ASID
+#ifdef CONFIG_QCOM_FALKOR_ERRATUM_E1003
+alternative_if_not ARM64_WORKAROUND_QCOM_FALKOR_E1003
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+ nop
+alternative_else
+ mrs x2, ttbr0_el1 // get cuurent TTBR0_EL1
+ mov x3, #1 // reserved ASID
+ bfi x2, x3, #48, #16 // set the reserved ASID + old BADDR
+ msr ttbr0_el1, x2 // update TTBR0_EL1
+ isb
+ bfi x2, x0, #0, #48 // set the desired BADDR + reserved ASID
+ msr ttbr0_el1, x2 // update TTBR0_EL1
+ isb
+alternative_endif
+#endif
msr ttbr0_el1, x0 // set TTBR0
isb
alternative_if ARM64_WORKAROUND_CAVIUM_27456
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/3] arm64: Define Qualcomm Technologies Falkor v1 CPU
From: Christopher Covington @ 2016-12-07 20:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Shanker Donthineni <shankerd@codeaurora.org>
This patch adds the cputype info for Qualcomm Technologies ARMv8 CPU
implementer ID 0x51 and part number for Falkor v1 in cputype.h.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 26a68dd..ee60561 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -71,6 +71,7 @@
#define ARM_CPU_IMP_APM 0x50
#define ARM_CPU_IMP_CAVIUM 0x43
#define ARM_CPU_IMP_BRCM 0x42
+#define ARM_CPU_IMP_QCOM 0x51
#define ARM_CPU_PART_AEM_V8 0xD0F
#define ARM_CPU_PART_FOUNDATION 0xD00
@@ -84,10 +85,13 @@
#define BRCM_CPU_PART_VULCAN 0x516
+#define QCOM_CPU_PART_FALKOR_V1 0x800
+
#define MIDR_CORTEX_A53 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A53)
#define MIDR_CORTEX_A57 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A57)
#define MIDR_THUNDERX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
#define MIDR_THUNDERX_81XX MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX_81XX)
+#define MIDR_QCOM_FALKOR_V1 MIDR_CPU_MODEL(ARM_CPU_IMP_QCOM, QCOM_CPU_PART_FALKOR_V1)
#ifndef __ASSEMBLY__
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v3 1/6] crypto: testmgr - avoid overlap in chunked tests
From: Ard Biesheuvel @ 2016-12-07 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207191920.GA139213@google.com>
On 7 December 2016 at 19:19, Eric Biggers <ebiggers@google.com> wrote:
> On Mon, Dec 05, 2016 at 06:42:23PM +0000, Ard Biesheuvel wrote:
>> The IDXn offsets are chosen such that tap values (which may go up to
>> 255) end up overlapping in the xbuf allocation. In particular, IDX1
>> and IDX3 are too close together, so update IDX3 to avoid this issue.
>>
>
> Hi Ard,
>
> This patch is causing the self-tests for "xts(ecb(aes-asm))" to fail.
> This is on x86. Any idea why?
Does this help at all?
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 670893bcf361..59e67f5b544b 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -63,7 +63,7 @@ int alg_test(const char *driver, const char *alg,
u32 type, u32 mask)
*/
#define IDX1 32
#define IDX2 32400
-#define IDX3 511
+#define IDX3 1511
#define IDX4 8193
#define IDX5 22222
#define IDX6 17101
> Here's what I see in the log:
>
> alg: skcipher: Chunk test 1 failed on encryption at page 0 for xts(ecb(aes-asm))
> 00000000: 1c 3b 3a 10 2f 77 03 86 e4 83 6c 99 e3 70 cf 9b
> 00000010: ea 00 80 3f 5e 48 23 57 a4 ae 12 d4 14 a3 e6 3b
> 00000020: 5d 31 e2 76 f8 fe 4a 8d 66 b3 17 f9 ac 68 3f 44
> 00000030: 68 0a 86 ac 35 ad fc 33 45 be fe cb 4b b1 88 fd
> 00000040: 57 76 92 6c 49 a3 09 5e b1 08 fd 10 98 ba ec 70
> 00000050: aa a6 69 99 a7 2a 82 f2 7d 84 8b 21 d4 a7 41 b0
> 00000060: c5 cd 4d 5f ff 9d ac 89 ae ba 12 29 61 d0 3a 75
> 00000070: 71 23 e9 87 0f 8a cf 10 00 02 08 87 89 14 29 ca
> 00000080: 2a 3e 7a 7d 7d f7 b1 03 55 16 5c 8b 9a 6d 0a 7d
> 00000090: e8 b0 62 c4 50 0d c4 cd 12 0c 0f 74 18 da e3 d0
> 000000a0: b5 78 1c 34 80 3f a7 54 21 c7 90 df e1 de 18 34
> 000000b0: f2 80 d7 66 7b 32 7f 6c 8c d7 55 7e 12 ac 3a 0f
> 000000c0: 93 ec 05 c5 2e 04 93 ef 31 a1 2d 3d 92 60 f7 9a
> 000000d0: 28 9d 6a 37 9b c7 0c 50 84 14 73 d1 a8 cc 81 ec
> 000000e0: 58 3e 96 45 e0 7b 8d 96 70 65 5b a5 bb cf ec c6
> 000000f0: dc 39 66 38 0a d8 fe cb 17 b6 ba 02 46 9a 02 0a
> 00000100: 84 e1 8e 8f 84 25 20 70 c1 3e 9f 1f 28 9b e5 4f
> 00000110: bc 48 14 57 77 8f 61 60 15 e1 32 7a 02 b1 40 f1
> 00000120: 50 5e b3 09 32 6d 68 37 8f 83 74 59 5c 84 9d 84
> 00000130: f4 c3 33 ec 44 23 88 51 43 cb 47 bd 71 c5 ed ae
> 00000140: 9b e6 9a 2f fe ce b1 be c9 de 24 4f be 15 99 2b
> 00000150: 11 b7 7c 04 0f 12 bd 8f 6a 97 5a 44 a0 f9 0c 29
> 00000160: a9 ab c3 d4 d8 93 92 72 84 c5 87 54 cc e2 94 52
> 00000170: 9f 86 14 dc d2 ab a9 91 92 5f ed c4 ae 74 ff ac
> 00000180: 6e 33 3b 93 eb 4a ff 04 79 da 9a 41 0e 44 50 e0
> 00000190: dd 7a e4 c6 e2 91 09 00 57 5d a4 01 fc 07 05 9f
> 000001a0: 64 5e 8b 7e 9b fd ef 33 94 30 54 ff 84 01 14 93
> 000001b0: c2 7b 34 29 ea ed b4 ed 53 76 44 1a 77 ed 43 85
> 000001c0: 1a d7 7f 16 f5 41 df d2 69 d5 0d 6a 5f 14 fb 0a
> 000001d0: 1e 2a 8f 42 61 9e 5e c2 59 bd 96 d0 e5 cc 23 1f
> 000001e0: fb 84 ed 15 a8 eb 66 07 31 6b f6 ef
>
> Eric
^ permalink raw reply related
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