* [PATCH v4] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Herbert Xu @ 2016-11-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9RVFQ4SNzbHbNCFSXy01b+_dCeRc4bXgZagovGy9BYtQ@mail.gmail.com>
On Mon, Nov 28, 2016 at 09:50:33AM +0000, Ard Biesheuvel wrote:
>
> Assuming that everyone is happy now (Will?), could we get this one
> queued for v4.10? The CRC stuff I sent over the past week can wait for
> v4.11 (and I should probably do a v2 roundup with everything
> combined), but this patch is good to go IMO
Sorry, I overlooked it because it wasn't in patchwork. I have
applied it now and will push it out soon.
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
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 11:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA9JUOHnJL59EuhQ_dEWjt+YjEcu8LGiJ3CSk_7R4J5Efg@mail.gmail.com>
On Mon, Nov 28, 2016 at 11:14:48AM +0000, Peter Maydell wrote:
> On 28 November 2016 at 11:12, Alex Benn?e <alex.bennee@linaro.org> wrote:
> >
> > Andrew Jones <drjones@redhat.com> writes:
> >> I've skimmed over everything looking at it from a framwork/sytle
> >> perspective. I didn't dig in trying to understand the tests though.
> >> One general comment, I see many tests introduce MAX_CPUS 8. Why do
> >> that? Why not allow all cpus by using NR_CPUS for the array sizes?
> >
> > Yeah - I can fix those. I wonder what the maximum is with GIC V3?
>
> So large that you don't want to hardcode it as an array size...
255 with the gic series, not yet merged. Even if you have a dozen arrays
with that as the size, then unless your array element size is huge (on
the order multiple pages), then it probably doesn't matter. Using the
default memory allocation of a QEMU guest, 128 MB, unit tests have plenty
of memory at their disposal. The framework itself only allocates a handful
of pages.
Of course the framework also supports dynamic memory allocation, so you
could do malloc(nr_cpus * element_size), to avoid excess.
Thanks,
drew
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Dave Martin @ 2016-11-28 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126113038.GA86651@MBP.local>
On Sat, Nov 26, 2016 at 11:30:42AM +0000, Catalin Marinas wrote:
> On Fri, Nov 25, 2016 at 08:45:02PM +0000, Ard Biesheuvel wrote:
> > On 25 November 2016 at 19:39, Dave Martin <Dave.Martin@arm.com> wrote:
> > > In order to enable CONFIG_KERNEL_MODE_NEON and things that rely on
> > > it to be configured together with Scalable Vector Extension support
> > > in the same kernel, this patch implements basic support for
> > > saving/restoring the SVE state around kernel_neon_begin()...
> > > kernel_neon_end().
> > >
> > > This patch is not optimal and will generally save more state than
> > > necessary, more often than necessary. Further optimisations can be
> > > implemented in future patches.
> > >
> > > This patch is not intended to allow general-purpose _SVE_ code to
> > > execute in the kernel safely. That functionality may also follow
> > > in later patches.
> > >
> > > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > > ---
> > > arch/arm64/Kconfig | 1 -
> > > arch/arm64/kernel/fpsimd.c | 22 ++++++++++++++++++----
> > > 2 files changed, 18 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index e8d04dd..7266761 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -880,7 +880,6 @@ endmenu
> > > config ARM64_SVE
> > > bool "ARM Scalable Vector Extension support"
> > > default y
> > > - depends on !KERNEL_MODE_NEON # until it works with SVE
> > > help
> > > The Scalable Vector Extension (SVE) is an extension to the AArch64
> > > execution state which complements and extends the SIMD functionality
> > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> > > index 81cfdb5..cb947dd 100644
> > > --- a/arch/arm64/kernel/fpsimd.c
> > > +++ b/arch/arm64/kernel/fpsimd.c
> > > @@ -282,11 +282,26 @@ static DEFINE_PER_CPU(struct fpsimd_partial_state, softirq_fpsimdstate);
> > > */
> > > void kernel_neon_begin_partial(u32 num_regs)
> > > {
> > > + preempt_disable();
> > > +
> > > + /*
> > > + * For now, we have no special storage for SVE registers in
> > > + * interrupt context, so always save the userland SVE state
> > > + * if there is any, even for interrupts.
> > > + */
> > > + if (IS_ENABLED(CONFIG_ARM64_SVE) && (elf_hwcap & HWCAP_SVE) &&
> > > + current->mm &&
> > > + !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE)) {
> > > + fpsimd_save_state(¤t->thread.fpsimd_state);
> > > + this_cpu_write(fpsimd_last_state, NULL);
> > > + }
> > > +
> >
> > I am having trouble understanding why we need all of this if we don't
> > support SVE in the kernel. Could you elaborate?
>
> Dave knows all the details but a reason is that touching a Neon register
> zeros the upper SVE state in the same vector register. So we can't
> safely save/restore just the Neon part without corrupting the SVE state.
This is right -- this also means that EFI services can trash the upper
bits of an SVE vector register (as a side-effect of FPSIMD/NEON usage).
It's overkill to save/restore absolutely everything -- I ignore num_regs
for example -- but I wanted to keep things as simple as possible
initially.
Cheers
---Dave
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Adrian Hunter @ 2016-11-28 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <66751ab5-59a4-ec30-07cd-44ca03694723@laposte.net>
On 28/11/16 13:20, Sebastian Frias wrote:
> Hi Adrian,
>
> On 28/11/16 11:30, Adrian Hunter wrote:
>> On 28/11/16 09:32, Michal Simek wrote:
>>> +Sai for Xilinx perspective.
>>>
>>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>>> Hi,
>>>>
>>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>>> "Hardware initialized registers"
>>>>
>>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>>> AHB Host Controller", revision 6.0 document)
>>>>
>>>> In some platforms those signals are connected to registers that need to
>>>> be programmed at some point for proper driver/HW initialisation.
>>>>
>>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>>> candidate for a place to program those registers (*).
>>>>
>>>> Do you agree?
>>
>> We already killed .platform_init
>
> I just saw that, yet it was the perfect place for the HW initialisation I'm
> talking about.
> Any way we can restore it?
It doesn't serve any purpose I am aware of.
>
>>
>> What is wrong with sdhci_arasan_probe()?
>
> Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
> put a call to it just before sdhci_pltfm_init(), something like:
>
> +static const struct of_device_id sdhci_arasan_of_match[] = {
> + {
> + .compatible = "arasan,sdhci-8.9a",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "arasan,sdhci-5.1",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "arasan,sdhci-4.9a",
> + .data = &sdhci_arasan_ops,
> + },
> + {
> + .compatible = "sigma,smp8734-sdio",
> + .data = &sdhci_arasan_tango4_ops,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
>
> ...
>
> + const struct of_device_id *match;
> +
> + match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
> + if (match)
> + sdhci_arasan_pdata.ops = match->data;
>
> where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
> callback.
>
> However, as I stated earlier, an upstream commit:
>
> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
> Author: Douglas Anderson <dianders@chromium.org>
> Date: Mon Jun 20 10:56:47 2016 -0700
>
> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>
> changed struct 'sdhci_arasan_of_match' to convey different data, which
> means that instead of having a generic way of accessing such data (such
> as 'of_match_device()' and ".data" field), one must also check for
> specific "compatible" strings to make sense of the ".data" field, such as
> "rockchip,rk3399-sdhci-5.1"
>
> With the current code:
> - there's no 'of_match_device()' before 'sdhci_pltfm_init()'
> - the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
> struct (so it cannot be made dependent on the "compatible" string).
> - since 'sdhci_arasan_pdata' is the same for all compatible devices, even
> for those that require special handling, more "compatible" matching code is
> required
> - leading to spread "compatible" matching code; IMHO it would be cleaner if
> the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
> matching, which then proceeded with specific initialisation and generic
> initialisation.
>
> In a nutshell, IMHO it would be better if adding support for more SoCs only
> involved changing just 'sdhci_arasan_of_match' without the need to change
> 'sdhci_arasan_probe()'.
> That would clearly separate the generic and "SoC"-specific code, thus allowing
> better maintenance.
>
> Does that makes sense to you guys?
If you want to do that, then why not define your match data with your own
callbacks. e.g. something like
struct sdhci_arasan_of_data {
struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
void (*platform_init)(struct sdhci_arasan_data *sdhci_arasan);
};
struct sdhci_arasan_of_data *data;
data = match->data;
sdhci_arasan->soc_ctl_map = data->soc_ctl_map;
if (data->platform_init)
platform_init(sdhci_arasan);
>
> Best regards,
>
> Sebastian
>
>>
>>>>
>>>> Best regards,
>>>>
>>>> Sebastian
>>>>
>>>>
>>>> (*): This has been prototyped on 4.7 as working properly.
>>>> However, upstream commit:
>>>>
>>>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>>>> Author: Douglas Anderson <dianders@chromium.org>
>>>> Date: Mon Jun 20 10:56:47 2016 -0700
>>>>
>>>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>>> ...
>>>>
>>>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>>>> struct is used after that commit.
>>>>
>>>
>>>
>>
>
>
^ permalink raw reply
* [GIT PULL 4/4] DaVinci defconfig updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit a652baa06413a4beacc09425883e518c5f1ed100:
ARM: davinci_all_defconfig: add missing options for systemd (2016-11-15 15:44:52 +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-3
for you to fetch changes up to 213971e7571e27f47b4e926904a9adf794925c51:
ARM: davinci_all_defconfig: Enable OHCI as module (2016-11-22 20:50:46 +0530)
----------------------------------------------------------------
A patch enabling USB OHCI support in davinci
defconfig.
----------------------------------------------------------------
Axel Haslam (1):
ARM: davinci_all_defconfig: Enable OHCI as module
arch/arm/configs/davinci_all_defconfig | 1 +
1 file changed, 1 insertion(+)
^ permalink raw reply
* [GIT PULL 3/4] DaVinci DT updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 83de086cc89410a8d4e0b6345e8a1116797ea703:
ARM: dts: da850-lcdk: Enable the usb otg device node (2016-11-20 17:02:18 +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-3
for you to fetch changes up to 878e908ad95637dc6567a9b5f6876a580ae90dfa:
ARM: dts: da850: enable memctrl and mstpri nodes per board (2016-11-28 15:51:29 +0530)
----------------------------------------------------------------
Some fixes for device-tree patches already queued.
- Fix SD card detect polarity
- Prevent Ethernet from picking a random mac address
- Fix error messages on platforms which dont use
bus master and emif priority settings.
----------------------------------------------------------------
Axel Haslam (1):
ARM: dts: da850-lcdk: fix mmc card detect polarity
Bartosz Golaszewski (1):
ARM: dts: da850: enable memctrl and mstpri nodes per board
Fabien Parent (1):
ARM: dts: da850-lcdk: Add ethernet0 alias to DT
arch/arm/boot/dts/da850-lcdk.dts | 11 ++++++++++-
arch/arm/boot/dts/da850.dtsi | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
^ permalink raw reply
* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 7e431af8fa0b9ed9d74378c99514856211cb9db8:
ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +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/soc-3
for you to fetch changes up to b5e1438cf98a1c588726b0f861178f9aa5a96caf:
ARM: davinci: da830-evm: use gpio descriptor for mmc pins (2016-11-28 14:01:17 +0530)
----------------------------------------------------------------
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.
----------------------------------------------------------------
Axel Haslam (4):
ARM: davinci: da8xx: Fix ohci device name
ARM: davinci: hawk: use gpio descriptor for mmc pins
ARM: davinci: da850-evm: use gpio descriptor for mmc pins
ARM: davinci: da830-evm: use gpio descriptor for mmc pins
arch/arm/mach-davinci/board-da830-evm.c | 41 ++++++++--------------------
arch/arm/mach-davinci/board-da850-evm.c | 35 +++++++-----------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 42 ++++++++---------------------
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 4 +--
7 files changed, 37 insertions(+), 91 deletions(-)
^ permalink raw reply
* [GIT PULL 1/4] DaVinci driver updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 8e7223fc8626db7c302136747bb68213100d290c:
bus: davinci: add support for da8xx bus master priority control (2016-11-14 17:20: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/drivers-2
for you to fetch changes up to d0c7546f6257b4680a760e3fd0dff8a7cc4600ff:
memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name() (2016-11-23 20:26:42 +0530)
----------------------------------------------------------------
Fixes for drivers already queued to prevent
section mismatch warnings introduced by them.
----------------------------------------------------------------
Bartosz Golaszewski (2):
bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name()
memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name()
drivers/bus/da8xx-mstpri.c | 4 +---
drivers/memory/da8xx-ddrctl.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL 0/4] DaVinci for v4.10 (set #4)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the fourth set of DaVinci pull requests for v4.10.
The first two were picked up, the third one is pending:
https://www.spinics.net/lists/arm-kernel/msg543902.html
Please pull above before pulling this one.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-28 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFo3ezYOywtSZ8GGQ1XK9KPsxCgQNbaiz45EVgbgtnUxjg@mail.gmail.com>
Hi Ulf,
On 2016/11/28 19:13, Ulf Hansson wrote:
>>
>> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
>> send commands for testing current sampling point set in our host PHY.
>>
>> According to my test result, it shows that mmc_send_tuning() can only support
>> tuning command (CMD21/CMD19).
>> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
>> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
>> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
>> speed modes.
>>
>> Could you please provide suggestions for the speed mode in which tuning is
>> not available?
>>
>
> Normally the mmc host driver shouldn't have to care about what the
> card supports, as that is the responsibility of the mmc core to
> manage.
>
> The host should only need to implement the ->execute_tuning() ops,
> which gets called when the card supports tuning (CMD19/21). Does it
> make sense?
>
I think it is irrelevant to tuning procedure.
Our host requires to adjust PHY setting after each time ios setting
(SDCLK/bus width/speed mode) is changed.
The simplified sequence is:
mmc change ios --> mmc_set_ios() --> ->set_ios() --> after sdhci_set_ios(),
adjust PHY setting.
During PHY setting adjustment, out host driver has to send commands to
test current sampling point. Tuning is another independent step.
Thus our host needs a valid command in PHY setting adjustment. Tuning command
can be borrowed to complete this task in SD SDR50. But for other speed mode,
we have to find out a valid command.
Any suggestion please?
Thank you.
Best regards,
Hu Ziji
> Kind regards
> Uffe
>
^ permalink raw reply
* [PATCH v2] drm: tilcdc: fix parsing of some DT properties
From: Bartosz Golaszewski @ 2016-11-28 11:37 UTC (permalink / raw)
To: linux-arm-kernel
The DT binding for tildc is not consistent with the driver code: there
are two options - 'max-width' and 'max-pixelclock' specified in the
documentation which are parsed as 'ti,max-width' and
'ti'max-pixelclock' respectively.
Make the driver code consistent with the binding.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- fix max-pixelclock too
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 5efb369..bd0a3bd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -296,12 +296,12 @@ static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
- if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
+ if (of_property_read_u32(node, "max-width", &priv->max_width))
priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
- if (of_property_read_u32(node, "ti,max-pixelclock",
+ if (of_property_read_u32(node, "max-pixelclock",
&priv->max_pixelclock))
priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [kvm-unit-tests PATCH v7 03/11] run_tests: allow passing of options to QEMU
From: Alex Bennée @ 2016-11-28 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128091051.zvtsvoow34b2nd5w@kamzik.brq.redhat.com>
Andrew Jones <drjones@redhat.com> writes:
> On Thu, Nov 24, 2016 at 04:10:25PM +0000, Alex Benn?e wrote:
>> This introduces a the option -o for passing of options directly to QEMU
>> which is useful. In my case I'm using it to toggle MTTCG on an off:
>>
>> ./run_tests.sh -t -o "-tcg mttcg=on"
>>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> run_tests.sh | 10 +++++++---
>> scripts/functions.bash | 13 +++++++------
>> 2 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/run_tests.sh b/run_tests.sh
>> index 4f2e5cb..05cc7fb 100755
>> --- a/run_tests.sh
>> +++ b/run_tests.sh
>> @@ -13,10 +13,11 @@ function usage()
>> {
>> cat <<EOF
>>
>> -Usage: $0 [-g group] [-a accel] [-t] [-h] [-v]
>> +Usage: $0 [-g group] [-a accel] [-o qemu_opts] [-t] [-h] [-v]
>>
>> -g: Only execute tests in the given group
>> -a: Force acceleration mode (tcg/kvm)
>> + -o: additional options for QEMU command line
>> -t: disable timeouts
>> -h: Output this help text
>> -v: Enables verbose mode
>> @@ -30,7 +31,7 @@ EOF
>> RUNTIME_arch_run="./$TEST_DIR/run"
>> source scripts/runtime.bash
>>
>> -while getopts "g:a:thv" opt; do
>> +while getopts "g:a:o:thv" opt; do
>> case $opt in
>> g)
>> only_group=$OPTARG
>> @@ -38,6 +39,9 @@ while getopts "g:a:thv" opt; do
>> a)
>> force_accel=$OPTARG
>> ;;
>> + o)
>> + extra_opts=$OPTARG
>> + ;;
>> t)
>> no_timeout="yes"
>> ;;
>> @@ -67,4 +71,4 @@ RUNTIME_log_stdout () {
>> config=$TEST_DIR/unittests.cfg
>> rm -f test.log
>> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
>> -for_each_unittest $config run
>> +for_each_unittest $config run "$extra_opts"
>> diff --git a/scripts/functions.bash b/scripts/functions.bash
>> index ee9143c..d38a69e 100644
>> --- a/scripts/functions.bash
>> +++ b/scripts/functions.bash
>> @@ -2,11 +2,12 @@
>> function for_each_unittest()
>> {
>> local unittests="$1"
>> - local cmd="$2"
>> - local testname
>> + local cmd="$2"
>> + local extra_opts=$3
>> + local testname
>
> We use tabs in this file. Not sure why cmd and testname got
> changed too...
>
>> local smp
>> local kernel
>> - local opts
>> + local opts=$extra_opts
>> local groups
>> local arch
>> local check
>> @@ -21,7 +22,7 @@ function for_each_unittest()
>> testname=${BASH_REMATCH[1]}
>> smp=1
>> kernel=""
>> - opts=""
>> + opts=$extra_opts
>> groups=""
>> arch=""
>> check=""
>> @@ -32,7 +33,7 @@ function for_each_unittest()
>> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
>> smp=${BASH_REMATCH[1]}
>> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
>> - opts=${BASH_REMATCH[1]}
>> + opts="$opts ${BASH_REMATCH[1]}"
>> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
>> groups=${BASH_REMATCH[1]}
>> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
>> @@ -45,6 +46,6 @@ function for_each_unittest()
>> timeout=${BASH_REMATCH[1]}
>> fi
>> done
>> - "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" "$accel" "$timeout"
>> + "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" "$accel" "$timeout"
>> exec {fd}<&-
>> }
>> --
>> 2.10.1
>>
>>
>
> This is a pretty good idea, but I think I might like the extra options
> to be given like this instead
>
> ./run_tests.sh [run_tests.sh options] -- [qemu options]
>
> Thanks,
> drew
That sounds like a better way, I'll fix that.
--
Alex Benn?e
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-11-28 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a949ade-edd7-4690-cd6a-434ae1e663dc@intel.com>
Hi Adrian,
On 28/11/16 11:30, Adrian Hunter wrote:
> On 28/11/16 09:32, Michal Simek wrote:
>> +Sai for Xilinx perspective.
>>
>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>> Hi,
>>>
>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>> "Hardware initialized registers"
>>>
>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>> AHB Host Controller", revision 6.0 document)
>>>
>>> In some platforms those signals are connected to registers that need to
>>> be programmed at some point for proper driver/HW initialisation.
>>>
>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>> candidate for a place to program those registers (*).
>>>
>>> Do you agree?
>
> We already killed .platform_init
I just saw that, yet it was the perfect place for the HW initialisation I'm
talking about.
Any way we can restore it?
>
> What is wrong with sdhci_arasan_probe()?
Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
put a call to it just before sdhci_pltfm_init(), something like:
+static const struct of_device_id sdhci_arasan_of_match[] = {
+ {
+ .compatible = "arasan,sdhci-8.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-5.1",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-4.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "sigma,smp8734-sdio",
+ .data = &sdhci_arasan_tango4_ops,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
...
+ const struct of_device_id *match;
+
+ match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
+ if (match)
+ sdhci_arasan_pdata.ops = match->data;
where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
callback.
However, as I stated earlier, an upstream commit:
commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Jun 20 10:56:47 2016 -0700
mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
changed struct 'sdhci_arasan_of_match' to convey different data, which
means that instead of having a generic way of accessing such data (such
as 'of_match_device()' and ".data" field), one must also check for
specific "compatible" strings to make sense of the ".data" field, such as
"rockchip,rk3399-sdhci-5.1"
With the current code:
- there's no 'of_match_device()' before 'sdhci_pltfm_init()'
- the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
struct (so it cannot be made dependent on the "compatible" string).
- since 'sdhci_arasan_pdata' is the same for all compatible devices, even
for those that require special handling, more "compatible" matching code is
required
- leading to spread "compatible" matching code; IMHO it would be cleaner if
the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
matching, which then proceeded with specific initialisation and generic
initialisation.
In a nutshell, IMHO it would be better if adding support for more SoCs only
involved changing just 'sdhci_arasan_of_match' without the need to change
'sdhci_arasan_probe()'.
That would clearly separate the generic and "SoC"-specific code, thus allowing
better maintenance.
Does that makes sense to you guys?
Best regards,
Sebastian
>
>>>
>>> Best regards,
>>>
>>> Sebastian
>>>
>>>
>>> (*): This has been prototyped on 4.7 as working properly.
>>> However, upstream commit:
>>>
>>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>>> Author: Douglas Anderson <dianders@chromium.org>
>>> Date: Mon Jun 20 10:56:47 2016 -0700
>>>
>>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>> ...
>>>
>>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>>> struct is used after that commit.
>>>
>>
>>
>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Maxime Ripard @ 2016-11-28 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124210834.a7da24a53b09364e8ab391d6@bidouilliste.com>
On Thu, Nov 24, 2016 at 09:08:34PM +0100, Emmanuel Vadot wrote:
> On Wed, 23 Nov 2016 18:16:10 +0100
> Emmanuel Vadot <manu@bidouilliste.com> wrote:
>
> > On Wed, 23 Nov 2016 09:03:50 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > > and uart pins along power in one connector and are found on most,
> > > > if not all, Olimex boards.
> > > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > > those two connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > >
> > > Fixed the indentation of the spi pinctrl cells, and applied.
> > >
> > > Please note that I'm note planning to send any new pull request, so
> > > this will likely end up in 4.11.
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Sorry about the indentation, I'll be more carefull next time.
> >
> > Thank you.
> >
> > --
> > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
> >
>
> Hi Maxime,
>
> Re-reading the patch I've seen that I've not enabled the SPI nodes, I
> guess it's easier if you revert my patch and that I send a new one ?
Just send the missing nodes, I'll squash the two commits.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/9bf0ed1f/attachment-0001.sig>
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Peter Maydell @ 2016-11-28 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878ts3uac6.fsf@linaro.org>
On 28 November 2016 at 11:12, Alex Benn?e <alex.bennee@linaro.org> wrote:
>
> Andrew Jones <drjones@redhat.com> writes:
>> I've skimmed over everything looking at it from a framwork/sytle
>> perspective. I didn't dig in trying to understand the tests though.
>> One general comment, I see many tests introduce MAX_CPUS 8. Why do
>> that? Why not allow all cpus by using NR_CPUS for the array sizes?
>
> Yeah - I can fix those. I wonder what the maximum is with GIC V3?
So large that you don't want to hardcode it as an array size...
thanks
-- PMM
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8359307d-5f44-3db9-aae1-eb1fe8e1141d@marvell.com>
>
> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
> send commands for testing current sampling point set in our host PHY.
>
> According to my test result, it shows that mmc_send_tuning() can only support
> tuning command (CMD21/CMD19).
> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
> speed modes.
>
> Could you please provide suggestions for the speed mode in which tuning is
> not available?
>
Normally the mmc host driver shouldn't have to care about what the
card supports, as that is the responsibility of the mmc core to
manage.
The host should only need to implement the ->execute_tuning() ops,
which gets called when the card supports tuning (CMD19/21). Does it
make sense?
Kind regards
Uffe
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Alex Bennée @ 2016-11-28 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128103744.s3wq53xzsxvu5uus@kamzik.brq.redhat.com>
Andrew Jones <drjones@redhat.com> writes:
> On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
>> Hi,
>>
>> Looking at my records it seems as though it has been a while since I
>> last posted these tests. As I'm hoping to get the final bits of MTTCG
>> merged upstream on the next QEMU development cycle I've been re-basing
>> these and getting them cleaned up for merging.
>>
>> Some of the patches might be worth taking now if the maintainers are
>> happy to do so (run_test tweaks, libcflat updates?). The others could
>> do with more serious review. I've CC'd some of the ARM guys to look
>> over the tlbflush/barrier tests so they can cast their expert eyes
>> over them ;-)
>>
>> There are two additions to the series.
>>
>> The tcg-test is a general torture test aimed at QEMU's TCG execution
>> model. It stresses the cpu execution loop through the use of
>> cross-page and computed jumps. It can also add IRQ's and self-modifying
>> code to the mix.
>>
>> The tlbflush-data test is a new one, the old tlbflush test is renamed
>> tlbflush-code to better indicate the code path it exercise. The the
>> code test tests the translation invalidation pathways in QEMU the data
>> test exercises the SoftMMU's TLBs and explicitly that tlbflush
>> completion semantics are correct.
>>
>> The tlbflush-data passes most of the times on real hardware but
>> definitely showed the problem with deferred TLB flushes running under
>> MTTCG QEMU. I've looked at some of the failure cases on real hardware
>> and it did look like a timestamp appeared on a page that shouldn't
>> have been accessible at the time - I don't know if this is a real
>> silicon bug or my misreading of the semantics so I'd appreciate
>> a comment from the experts.
>>
>> The code needs to be applied on top of Drew's latest ARM GIC patches
>> or you can grab my tree from:
>>
>> https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v7
>
> Thanks Alex,
>
> I've skimmed over everything looking at it from a framwork/sytle
> perspective. I didn't dig in trying to understand the tests though.
> One general comment, I see many tests introduce MAX_CPUS 8. Why do
> that? Why not allow all cpus by using NR_CPUS for the array sizes?
Yeah - I can fix those. I wonder what the maximum is with GIC V3?
>
> Thanks,
> drew
>
>>
>> Cheers,
>>
>> Alex.
>>
>> Alex Benn?e (11):
>> run_tests: allow forcing of acceleration mode
>> run_tests: allow disabling of timeouts
>> run_tests: allow passing of options to QEMU
>> libcflat: add PRI(dux)32 format types
>> lib: add isaac prng library from CCAN
>> arm/Makefile.common: force -fno-pic
>> arm/tlbflush-code: Add TLB flush during code execution test
>> arm/tlbflush-data: Add TLB flush during data writes test
>> arm/locking-tests: add comprehensive locking test
>> arm/barrier-litmus-tests: add simple mp and sal litmus tests
>> arm/tcg-test: some basic TCG exercising tests
>>
>> Makefile | 2 +
>> arm/Makefile.arm | 2 +
>> arm/Makefile.arm64 | 2 +
>> arm/Makefile.common | 11 ++
>> arm/barrier-litmus-test.c | 437 ++++++++++++++++++++++++++++++++++++++++++++++
>> arm/locking-test.c | 302 ++++++++++++++++++++++++++++++++
>> arm/tcg-test-asm.S | 170 ++++++++++++++++++
>> arm/tcg-test-asm64.S | 169 ++++++++++++++++++
>> arm/tcg-test.c | 337 +++++++++++++++++++++++++++++++++++
>> arm/tlbflush-code.c | 212 ++++++++++++++++++++++
>> arm/tlbflush-data.c | 401 ++++++++++++++++++++++++++++++++++++++++++
>> arm/unittests.cfg | 190 ++++++++++++++++++++
>> lib/arm/asm/barrier.h | 63 ++++++-
>> lib/arm64/asm/barrier.h | 50 ++++++
>> lib/libcflat.h | 5 +
>> lib/prng.c | 162 +++++++++++++++++
>> lib/prng.h | 82 +++++++++
>> run_tests.sh | 18 +-
>> scripts/functions.bash | 13 +-
>> scripts/runtime.bash | 8 +
>> 20 files changed, 2626 insertions(+), 10 deletions(-)
>> create mode 100644 arm/barrier-litmus-test.c
>> create mode 100644 arm/locking-test.c
>> create mode 100644 arm/tcg-test-asm.S
>> create mode 100644 arm/tcg-test-asm64.S
>> create mode 100644 arm/tcg-test.c
>> create mode 100644 arm/tlbflush-code.c
>> create mode 100644 arm/tlbflush-data.c
>> create mode 100644 lib/prng.c
>> create mode 100644 lib/prng.h
>>
>> --
>> 2.10.1
>>
>>
--
Alex Benn?e
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <436c6925-cb0d-afe7-e3a2-384eca15ff42@marvell.com>
[...]
>
> Could you please tell me the requirement of "op_code" parameter in
> mmc_send_tuning()?
> According to mmc_send_tuning(),it seems that tuning command(CMD19/CMD21)
> is required. Thus device will not response mmc_send_tuning() if current
> speed mode doesn't support tuning command.
> Please correct me if I am wrong.
>
When the mmc core decides it's time to execute tuning, it invokes the
->execute_tuning() host ops, which has the "opcode" as a parameter.
You should be able to use it when calling mmc_send_tuning().
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036@suse.de>
On Mon, Nov 28, 2016 at 11:52:26AM +0100, Andreas F?rber wrote:
> Hi Russell,
>
> Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> > On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
> >> To more consistently reference nodes by label, add labels for sata,
> >> usb2, sdhci and usb3 nodes.
> >>
> >> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
> >
> > Please don't do this for clearfog - there's changes in the pipeline which
> > completely replace armada-388-clearfog.dts because there's a "base" and
> > "pro" versions of this hardware now, and making such a huge change will
> > effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
What I mentioned is not a case of a work in progress, it's already out
in the wild, and completely changing the clearfog dts file by changing
the style of DT references will make applying the changes _much_ more
difficult - not only obviously impossible to apply the original patch,
but also quite impossible to identify the changes made downstream.
So, I'd rather armada-388-clearfog.dts is not touched at all as it _will_
cause conflicts, but I have nothing against the new style (and I actually
prefer it.)
What I'm asking is that you don't make other people's lives harder than
they need to be.
--
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] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e29e1a96-c9d5-d9b1-a42d-8afddc2714a7@kleine-koenig.org>
Hi,
Am 28.11.2016 um 11:54 schrieb Uwe Kleine-K?nig:
> On 11/28/2016 11:52 AM, Andreas F?rber wrote:
>> Would it help to split it back up into a series of add-labels,
>> use-labels like I had originally? Then you could start using them in
>> your refactoring as soon as the add-labels patch gets applied. Or are
>> you completely against this style?
>
> I'd even go as far as:
>
> 1: add labels to .dtsi
> 2: use labels on .dts#1
> 3: use labels on .dts#2
> ...
That was what I had in mind. :) I even considered reusing the existing
labels first, then adding more and converting more nodes.
Making the patches smaller will hopefully make them more easily
reviewable at the same time.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Uwe Kleine-König @ 2016-11-28 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036@suse.de>
Hello,
On 11/28/2016 11:52 AM, Andreas F?rber wrote:
>> Please don't do this for clearfog - there's changes in the pipeline which
>> completely replace armada-388-clearfog.dts because there's a "base" and
>> "pro" versions of this hardware now, and making such a huge change will
>> effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
I'd even go as far as:
1: add labels to .dtsi
2: use labels on .dts#1
3: use labels on .dts#2
...
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/10666366/attachment.sig>
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Will Deacon @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVPsHjh3CWjdUrKB_r6=hkXK=qS3wpykbacdKe1rzz1H8Q@mail.gmail.com>
Hi Ming,
On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
> When I run stress-ng via the following steps on one ARM64 dual
> socket system(Cavium Thunder), the kernel oops[1] can often be
> triggered after running the stress test for several hours(sometimes
> it may take longer):
>
> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
> - apply the attachment patch which just makes the posix file
> lock stress test more aggressive
> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>
>
> From the oops log, looks one garbage file_lock node is got
> from the linked list of 'ctx->flc_posix' when the issue happens.
>
> BTW, the issue isn't observed on single socket Cavium Thunder yet,
> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
> too.
I've seen issues with the LSE atomics on the Thunder platform -- can you
try disabling those (CONFIG_ARM64_LSE_ATOMICS) and see if the problem
persists, please?
Will
^ permalink raw reply
* [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously
From: majun (Euler7) @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-2-git-send-email-agustinv@codeaurora.org>
This patch works fine on my D05 board.
Tested-by: Majun <majun258@huawei.com>
? 2016/11/14 5:59, Agustin Vega-Frias ??:
> This allows probe deferral to work properly when a dependent device
> fails to get a valid IRQ because the IRQ domain was not registered
> at the time the resources were added to the platform_device.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/resource.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/base/platform.c | 9 +++++++-
> include/linux/acpi.h | 7 ++++++
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..4beda15 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct acpi_resource *ares,
> return (type & types) ? 0 : 1;
> }
> EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
> +
> +struct acpi_irq_get_ctx {
> + unsigned int index;
> + struct resource *res;
> +};
> +
> +static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_irq_get_ctx *ctx = context;
> + struct acpi_resource_irq *irq;
> + struct acpi_resource_extended_irq *ext_irq;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_IRQ:
> + irq = &ares->data.irq;
> + if (ctx->index < irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= irq->interrupt_count;
> + break;
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = &ares->data.extended_irq;
> + if (ctx->index < ext_irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= ext_irq->interrupt_count;
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +/**
> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> + * use it to initialize the given Linux IRQ resource.
> + * @handle ACPI device handle
> + * @index ACPI IRQ resource index to lookup
> + * @res Linux IRQ resource to initialize
> + *
> + * Return: 0 on success
> + * -EINVAL if an error occurs
> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> + */
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> +{
> + struct acpi_irq_get_ctx ctx = { index, res };
> + acpi_status status;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_irq_get_cb, &ctx);
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> + if (res->flags & IORESOURCE_DISABLED)
> + return -EPROBE_DEFER;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_get);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..61423d2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> }
>
> r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> + if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(&dev->dev)) {
> + int ret;
> +
> + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> + if (ret)
> + return ret;
> + }
> +
> /*
> * The resources may pass trigger flags to the irqs that need
> * to be set up. It so happens that the trigger flags for
> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> }
> }
> -
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 689a8b9..325bdb9 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
> unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res);
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
>
> void acpi_dev_free_resource_list(struct list_head *list);
> int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> @@ -763,6 +764,12 @@ static inline int acpi_reconfig_notifier_unregister(struct notifier_block *nb)
> return -EINVAL;
> }
>
> +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> + struct resource *res)
> +{
> + return -EINVAL;
> +}
> +
> #endif /* !CONFIG_ACPI */
>
> #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
>
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128103738.GT14217@n2100.armlinux.org.uk>
Hi Russell,
Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
>> To more consistently reference nodes by label, add labels for sata,
>> usb2, sdhci and usb3 nodes.
>>
>> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
>
> Please don't do this for clearfog - there's changes in the pipeline which
> completely replace armada-388-clearfog.dts because there's a "base" and
> "pro" versions of this hardware now, and making such a huge change will
> effectively mean we have to start over with the DT files.
Would it help to split it back up into a series of add-labels,
use-labels like I had originally? Then you could start using them in
your refactoring as soon as the add-labels patch gets applied. Or are
you completely against this style?
Thanks for pointing this out,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-1-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and getting them cleaned up for merging.
>
> Some of the patches might be worth taking now if the maintainers are
> happy to do so (run_test tweaks, libcflat updates?). The others could
> do with more serious review. I've CC'd some of the ARM guys to look
> over the tlbflush/barrier tests so they can cast their expert eyes
> over them ;-)
>
> There are two additions to the series.
>
> The tcg-test is a general torture test aimed at QEMU's TCG execution
> model. It stresses the cpu execution loop through the use of
> cross-page and computed jumps. It can also add IRQ's and self-modifying
> code to the mix.
>
> The tlbflush-data test is a new one, the old tlbflush test is renamed
> tlbflush-code to better indicate the code path it exercise. The the
> code test tests the translation invalidation pathways in QEMU the data
> test exercises the SoftMMU's TLBs and explicitly that tlbflush
> completion semantics are correct.
>
> The tlbflush-data passes most of the times on real hardware but
> definitely showed the problem with deferred TLB flushes running under
> MTTCG QEMU. I've looked at some of the failure cases on real hardware
> and it did look like a timestamp appeared on a page that shouldn't
> have been accessible at the time - I don't know if this is a real
> silicon bug or my misreading of the semantics so I'd appreciate
> a comment from the experts.
One other thought. I'm not sure how best to approach a bunch of TCG-only
tests getting integrated. I'm thinking it might be nice to give them
their own subdir under the arch dir, e.g. arm/tcg. That subdir would
have its own unittests.cfg file too. Otherwise when we run on KVM we'll
have a load of "SKIP: requires TCG" type messages...
We'll want to add a run_tests.sh option to pass the name of the subdir,
'-d tcg'. When the subdir name is 'tcg' ACCEL could automatically be
switched to 'tcg' as well.
Thanks,
drew
^ 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