* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Robert Jarzmik @ 2016-11-25 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Stefan Schmidt <stefan@datenfreihafen.org> writes:
> Hello.
>
> On 24.11.2016 17:29, Arnd Bergmann wrote:
>> The camera_supply_dummy_device definition is shared between a780 and a910,
>> but only provided when the first is enabled and fails to build for a
>> configuration with only a910:
>>
>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>
>> This moves the definition into its own section.
>>
>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>
> I wonder what we should do with ezx.c.
>
> As far as I know neither Daniel nor Harald or myself are doing anything
> with this devices anymore. Besides a basic compile test having an ack or
> reviewed by from our side is a bit worthless. :/
>
> I should still have some of these phones around in a box somewhere. If
> there is someone with a good motivation and time to take over on this
> platform we will find a way to get the person this devices.
>
> Any takers? Robert? I guess you are already overloaded but you might
> also have an interest. Worth asking :)
Oh yes, I'm very interested in your box. Besides I really like old platforms
:)
> In the case nobody wants to pick up here what would you consider the
> bets way forward? I could send a patch removing ezx platform support
> from the kernel (basically ezx.c plus build support) or I can send a
> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
Unless another maintainer steps in, you can submit a patch to transfer the
maintainance onto me, and we'll see off mailing lists how we could arange the
boards transfer.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH 6/9] power_supply: wm97xx_battery: use power_supply_get_drvdata
From: Robert Jarzmik @ 2016-11-25 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123231320.fo3kilw5h7cctngc@earth>
Sebastian Reichel <sre@kernel.org> writes:
> Hi Robert,
>
> On Wed, Oct 26, 2016 at 09:41:44PM +0200, Robert Jarzmik wrote:
>> As the power supply framework provides a way to store and retrieve
>> private supply data, use it.
>>
>> In the process, change the platform data for wm97xx_battery from a
>> container of a single struct wm97xx_batt_pdata to the direct point to wm97xx_batt_pdata.
>>
>> Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>> ---
>> drivers/input/touchscreen/wm97xx-core.c | 2 +-
>> drivers/power/supply/wm97xx_battery.c | 25 ++++++++++---------------
>> 2 files changed, 11 insertions(+), 16 deletions(-)
>
> I queued this into power-supply's for-next branch.
Thanks Sebastian.
Cheers.
--
Robert
^ permalink raw reply
* [alsa-devel] [PATCH 2/9] ALSA: ac97: add an ac97 bus
From: Robert Jarzmik @ 2016-11-25 19:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b97a129-bd10-b9be-616d-a3ea3b91b103@metafoo.de>
Lars-Peter Clausen <lars@metafoo.de> writes:
...
Ok Lars, let's do this : I integrate as many of your remarks as I can, and I
respin this serie, limited to patches 1, 2, 3, 4 and 5.
Then we'll iterate, that will enable me to settle the serie, as I was on
holidays and lost a bit my track. I'll send it hopefully next week once I've
gathered my thoughts.
Cheers.
--
Robert
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Harald Welte @ 2016-11-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e0bdf159-93f2-5ed7-1e28-7fb80707d6c7@datenfreihafen.org>
Hi Stefan,
On Thu, Nov 24, 2016 at 11:10:09PM +0100, Stefan Schmidt wrote:
> Daniel, Harald, if one of you is still interested in these and what to
> pick up the work again, please speak up now. :)
I have no interest, motivtaion nor time to still work on ezx support. I
guess the number of people running a recent kernel on more than 10 year
old 2G-only phones is pretty low these days.
If anyone has a serious interest in taking this over, I think I still
have some A780 and A1200 units that I am happy to provide.
Regards,
Harald
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* [RFC PATCH 06/29] arm64: efi: Add missing Kconfig dependency on KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-7-git-send-email-Dave.Martin@arm.com>
On 25 November 2016 at 19:38, Dave Martin <Dave.Martin@arm.com> wrote:
> The EFI runtime services ABI permits calls to EFI to clobber
> certain FPSIMD/NEON registers, as per the AArch64 procedure call
> standard.
>
> Saving/restoring the clobbered registers around such calls needs
> KERNEL_MODE_NEON, but the dependency is missing from Kconfig.
>
> This patch adds the missing dependency.
>
> This will aid bisection of the patches implementing support for the
> ARM Scalable Vector Extension (SVE).
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 969ef88..d008bb6 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -963,6 +963,7 @@ config EFI_STUB
> config EFI
> bool "UEFI runtime support"
> depends on OF && !CPU_BIG_ENDIAN
> + depends on KERNEL_MODE_NEON
> select LIBFDT
> select UCS2_STRING
> select EFI_PARAMS_FROM_FDT
> --
> 2.1.4
>
^ permalink raw reply
* [RFC PATCH 13/29] arm64/sve: Basic support for KERNEL_MODE_NEON
From: Ard Biesheuvel @ 2016-11-25 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480102762-23647-14-git-send-email-Dave.Martin@arm.com>
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?
> if (in_interrupt()) {
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> -
> BUG_ON(num_regs > 32);
> +
> + /* Save partial state for interrupted kernel-mode NEON code: */
> fpsimd_save_partial_state(s, roundup(num_regs, 2));
> } else {
> /*
> @@ -295,7 +310,6 @@ void kernel_neon_begin_partial(u32 num_regs)
> * that there is no longer userland FPSIMD state in the
> * registers.
> */
> - preempt_disable();
> if (current->mm &&
> !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state(¤t->thread.fpsimd_state);
> @@ -310,9 +324,9 @@ void kernel_neon_end(void)
> struct fpsimd_partial_state *s = this_cpu_ptr(
> in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
> fpsimd_load_partial_state(s);
> - } else {
> - preempt_enable();
> }
> +
> + preempt_enable();
> }
> EXPORT_SYMBOL(kernel_neon_end);
>
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Add num-cs for A20 spi nodes
From: Emmanuel Vadot @ 2016-11-25 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125152047.oadxi2xbgm4kdd7q@lukather>
On Fri, 25 Nov 2016 16:20:47 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Nov 24, 2016 at 09:05:09PM +0100, Emmanuel Vadot wrote:
> > On Thu, 24 Nov 2016 20:55:17 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > On Tue, Nov 22, 2016 at 06:06:16PM +0100, Emmanuel Vadot wrote:
> > > > The spi0 controller on the A20 have up to 4 CS (Chip Select) while the
> > > > others three only have 1.
> > > > Add the num-cs property to each node.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > >
> > > I don't think we have any code that uses it at the moment. What is the
> > > rationale behind this patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Hi Maxime,
> >
> > If num-cs isn't present nothing prevent to start a transfer with a
> > non-valid CS pin, resulting in an error.
> > num-cs are default property especially made for this and a SPI driver
> > should try to get the property at probe/attach time.
>
> Yes, but as far as I know, our driver doesn't. I'm all in for having
> support for that in our driver, but without it, that patch is kind of
> useless.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
Yes the Linux driver doesn't use it but my upcoming one for FreeBSD
uses it. So it is not useless for downstream user of DTS.
Cheers,
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [GIT PULL] Allwinner fixes for 4.9, take 2
From: Arnd Bergmann @ 2016-11-25 21:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122143134.wxinkyp3x6jjnk7e@lukather>
On Tuesday, November 22, 2016 3:31:34 PM CET Maxime Ripard wrote:
> Allwinner fixes for 4.9, second iteration
>
> A renaming of the GR8 DTSI and DTS to make it explicitly part of the sun5i
> family.
>
Pulled into the fixe branch, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] STi DT fix for v4.9-rcs round 2
From: Arnd Bergmann @ 2016-11-25 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d109e729-0d50-40ac-ceeb-16d88a7a3e74@st.com>
On Wednesday, November 23, 2016 9:59:16 AM CET Patrice Chotard wrote:
> STi DT fix:
>
> The I2C nodes are missing #address-cells and #size-cells.
> This is causing warning at device tree compilation when
> some I2C device sub-nodes are defined.
>
>
Pulled into fixes branch, thanks!
Arnd
^ permalink raw reply
* [GIT PULL] STi defconfig fix for v4.9-rcs
From: Arnd Bergmann @ 2016-11-25 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0492803d-d136-618d-bf06-51f0001d039b@st.com>
On Wednesday, November 23, 2016 9:59:14 AM CET Patrice Chotard wrote:
> STi defconfig fix:
>
> Enable HVA (Hardware Video Accelerator) video encoder
> driver for STMicroelectronics SoC.
Defconfig changes like this don't seem particularly urgent. Unless
there is a good reason, I'd suggest putting this into v4.10 instead.
Arnd
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Arnd Bergmann @ 2016-11-25 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161017204919.GE3264@localhost>
On Monday, October 17, 2016 1:49:19 PM CET Olof Johansson wrote:
> On Thu, Oct 13, 2016 at 08:31:20PM +0800, Jun Nie wrote:
> > GICR for multiple CPU can be described with start address and stride,
> > or with multiple address. Current multiple address and stride are
> > both used. Fix it.
> >
> > vmalloc patch 727a7f5a9 triggered this bug:
> > [ 0.097146] Unable to handle kernel paging request at virtual address ffff000008060008
> > [ 0.097150] pgd = ffff000008602000
> > [ 0.097160] [ffff000008060008] *pgd=000000007fffe003, *pud=000000007fffd003, *pmd=000000007fffc003, *pte=0000000000000000
> > [ 0.097165] Internal error: Oops: 96000007 [#1] PREEMPT SMP
> > [ 0.097170] Modules linked in:
> > [ 0.097177] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.8.0+ #1474
> > [ 0.097179] Hardware name: ZTE zx296718 evaluation board (DT)
> > [ 0.097183] task: ffff80003e8c8b80 task.stack: ffff80003e8d0000
> > [ 0.097197] PC is at gic_populate_rdist+0x74/0x15c
> > [ 0.097202] LR is at gic_starting_cpu+0xc/0x20
> > [ 0.097206] pc : [<ffff0000082b1b18>] lr : [<ffff0000082b26e0>] pstate: 600001c5
> >
> > Signed-off-by: Jun Nie <jun.nie@linaro.org>
>
> A Fixes: tag would be useful on a patch like this, to tell what patch
> introduced the problem. Please consider using them in the future.
>
> I've applied this one to fixes now.
Hi Olof,
I happened to still have this one in my todo folder as I must have
missed your reply, and I stumbled over it while looking for things
that may have gone missing.
I don't see it in v4.9-rc6, did it get dropped accidentally?
Arnd
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Arnd Bergmann @ 2016-11-25 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87inrbqr16.fsf@belgarion.home>
On Friday, November 25, 2016 8:48:53 PM CET Robert Jarzmik wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
>
> > The camera_supply_dummy_device definition is shared between a780 and a910,
> > but only provided when the first is enabled and fails to build for a
> > configuration with only a910:
> >
> > arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
> >
> > This moves the definition into its own section.
> >
> > Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Ah yes, I'll queue that up in pxa/fixes.
>
> This also means that you have a test robot which beats my Jenkins, as mine
> didn't complain. Do you have a specific defconfig or is it a randconfig which
> reveals that ?
>
It showed up in randconfig builds, two out of several hundred.
I'm not surprised that nobody else caught it.
Arnd
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Arnd Bergmann @ 2016-11-25 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512445.DtnT51NQqg@amdc3058>
On Monday, October 31, 2016 7:24:46 PM CET Bartlomiej Zolnierkiewicz wrote:
> On Monday, October 31, 2016 07:14:13 PM Bartlomiej Zolnierkiewicz wrote:
> > On Monday, October 31, 2016 03:46:22 PM Russell King - ARM Linux wrote:
> > > On Wed, Oct 26, 2016 at 07:01:12PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > > > I'd be fine with just getting a pull request with all the patches that
> > > > > had no negative feedback and that were not already applied (if any).
> > > >
> > > > Here it is (sorry for taking so long).
> > >
> > > I've just been digging in the dmesg logs from when I was using the
> > > Assabet+Neponset as my firewall, and it was having to use the IDE
> > > ide-cs driver rather than the pata pcmcia driver.
> > >
> > > I don't recall whether the pata pcmcia driver was a problem or not,
> > > as the PCMCIA interface can't cope with _any_ 32-bit accesses. I
> > > think PATA tries to use the "highest" possible access size by
> > > default...
> >
> > It doesn't actually - it defaults to 16-bits for PIO data access and
> > you must explicitly enable 32-bits using ATA_PFLAG_PIO32 port flag
> > (pata_pcmcia doesn't set it so it should be okay). Also taskfile
> > registers are accessed using 8-bits access by default transport
> > functions (which are used by pata_pcmcia).
>
> Please also note that:
>
> - assebet_defconfig currently doesn't even enable ide-cs
> (CONFIG_BLK_DEV_IDECS) in the mainline kernel
>
> - neponset_defconfig doesn't even enable IDE (CONFIG_IDE)
> in the mainline kernel
>
> so there is no risk of breaking anything..
I noticed this older pull request in my todo folder, my interpretation
is that the concern was resolved and we simply missed it.
I've pulled it into next/defconfig for v4.10 now, with the above
in the merge commit text for reference.
Thanks,
Arnd
^ permalink raw reply
* [PATCH 1/2] drivers: psci: PSCI checker module
From: Arnd Bergmann @ 2016-11-25 22:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108175547.31146-1-lorenzo.pieralisi@arm.com>
On Tuesday, November 8, 2016 5:55:46 PM CET Lorenzo Pieralisi wrote:
> From: Kevin Brodsky <kevin.brodsky@arm.com>
>
> On arm and arm64, PSCI is one of the possible firmware interfaces
> used for power management. This includes both turning CPUs on and off,
> and suspending them (entering idle states).
>
> This patch adds a PSCI checker module that enables basic testing of
> PSCI operations during startup. There are two main tests: CPU
> hotplugging and suspending.
>
> In the hotplug tests, the hotplug API is used to turn off and on again
> all CPUs in the system, and then all CPUs in each cluster, checking
> the consistency of the return codes.
>
> In the suspend tests, a high-priority thread is created on each core
> and uses low-level cpuidle functionalities to enter suspend, in all
> the possible states and multiple times. This should allow a maximum
> number of CPUs to enter the same sleep state at the same or slightly
> different time.
>
> In essence, the suspend tests use a principle similar to that of the
> intel_powerclamp driver (drivers/thermal/intel_powerclamp.c), but the
> threads are only kept for the duration of the test (they are already
> gone when userspace is started) and it does not require to stop/start
> the tick.
>
> While in theory power management PSCI functions (CPU_{ON,OFF,SUSPEND})
> could be directly called, this proved too difficult as it would imply
> the duplication of all the logic used by the kernel to allow for a
> clean shutdown/bringup/suspend of the CPU (the deepest sleep states
> implying potentially the shutdown of the CPU).
>
> Note that this file cannot be compiled as a loadable module, since it
> uses a number of non-exported identifiers (essentially for
> PSCI-specific checks and direct use of cpuidle) and relies on the
> absence of userspace to avoid races when calling hotplug and cpuidle
> functions.
>
> For now at least, CONFIG_PSCI_CHECKER is mutually exclusive with
> CONFIG_TORTURE_TEST, because torture tests may also use hotplug and
> cause false positives in the hotplug tests.
>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Kevin Hilman <khilman@kernel.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: James Morse <james.morse@arm.com>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> [torture test config]
> Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
> [lpieralisi: added cpuidle locking, reworded commit log/kconfig entry]
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Applied both patches to the next/drivers tree in arm-soc now, sorry
for the delay,
Arnd
^ permalink raw reply
* [GIT PULL] ARM: OXNAS SoC DT updates for 4.10
From: Arnd Bergmann @ 2016-11-25 23:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <85ecb958-a6cb-bdd2-10db-873e1b894ad7@baylibre.com>
On Friday, November 4, 2016 11:26:30 AM CET Neil Armstrong wrote:
> - Add DTSI for Oxford Semiconductor OX820
> - Add DTS for Cloud Engines PogoPlug v3 board
> - Fix MAINTAINERS Oxnas entry for dts files
> from http://lkml.kernel.org/r/20161102141850.25164-1-narmstrong at baylibre.com
>
>
This one seemed to have gone missing after Olof asked for a respin
of the other oxnas branch. I've pulled it into next/dt now.
I'd probably have put the MAINTAINERS update into a different
branch (possibly even for v4.9), but it doesn't seem too important
since there was no change in the maintainers and it's unlikely
to cause conflicts.
Arnd
^ permalink raw reply
* [PATCH net-next 1/5] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: kbuild test robot @ 2016-11-25 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e6004f918d3fcde9ae71e7893d26b19086236a3.1480087510.git-series.gregory.clement@free-electrons.com>
Hi Gregory,
[auto build test ERROR on ]
url: https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/Support-Armada-37xx-SoC-ARMv8-64-bits-in-mvneta-driver/20161126-050621
base:
config: parisc-allmodconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=parisc
Note: the linux-review/Gregory-CLEMENT/Support-Armada-37xx-SoC-ARMv8-64-bits-in-mvneta-driver/20161126-050621 HEAD 5f44108a5c983ae4477f811485fdc4ee12294e72 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
vim +2745 drivers/net/ethernet/marvell/mvneta.c
2739 DMA_FROM_DEVICE);
2740 if (unlikely(dma_mapping_error(pp->dev->dev.parent, phys_addr))) {
2741 mvneta_frag_free(pp->frag_size, data);
2742 return -ENOMEM;
2743 }
2744
> 2745 phys_addr += pp->rx_offset_correction;
2746 rx_desc->buf_phys_addr = phys_addr;
2747 rx_desc->buf_cookie = (uintptr_t)data;
2748
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 47218 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161126/8b9e6423/attachment-0001.gz>
^ permalink raw reply
* [GIT PULL] arm64: dts: uniphier: UniPhier DT updates (64bit) for v4.10
From: Arnd Bergmann @ 2016-11-25 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNASgYKnhpRM4jj1oHagK=MvO71QnbnaSr=Gt+hkV+6vxXg@mail.gmail.com>
On Sunday, November 6, 2016 12:25:15 AM CET Masahiro Yamada wrote:
> UniPhier ARM64 SoC DT updates for v4.10
>
> - Switch CPU enable-method from spin-table to PSCI
> - Add OPP tables to support generic cpufreq driver
> - Misc fixes
>
>
I don't see an email from Olof about merging this one,
for reference I have verified that he put it into the next/dt64
branch on Nov 17.
Arnd
^ permalink raw reply
* [GIT PULL]: ARM ARTPEC changes for 4.10
From: Arnd Bergmann @ 2016-11-25 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110150930.GB19804@axis.com>
On Thursday, November 10, 2016 4:09:31 PM CET Jesper Nilsson wrote:
> Please pull the below signed tag for a trio of minor changes
> adding PCIe for the ARM ARTPEC SoC.
>
> Thanks!
>
> /Jesper
>
> The following changes since commit bc33b0ca11e3df467777a4fa7639ba488c9d4911:
>
> Linux 4.9-rc4 (2016-11-05 16:23:36 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jesper/artpec.git tags/artpec-for-4.10
>
> for you to fetch changes up to fa5541fc806771a108cd2a48245a229f1ba539ea:
>
> ARM: dts: artpec: add pcie support (2016-11-10 15:51:10 +0100)
>
> ----------------------------------------------------------------
> ARTPEC changes for 4.10
>
> ----------------------------------------------------------------
> Niklas Cassel (3):
> ARM: ARTPEC-6: add select MFD_SYSCON to MACH_ARTPEC6
> ARM: ARTPEC-6: add pcie related options
> ARM: dts: artpec: add pcie support
>
>
Hi Jesper and Niklas,
I just found the old pull request while going through my mail backlog.
A few things for you to remember for next time:
- please send pull requests "To: arm at kernel.org" so we know they
are destined for arm-soc
- please split up changes to the platform code from dts changes,
defconfig changes and driver changes. Each of them gets sent
to Linus in a separate arm-soc branch, so we have to pull them
in separately too
- For the signed tag, please put in a cleartext description of
the branch, just like you describe each commit in its changelog
text. The tag comment becomes the merge commit text.
- I've looked at the three patches individually and cherry-picked
the first into next/soc and the third into next/dt. The patch
"ARM: ARTPEC-6: add pcie related options" is no longer needed
after commit e13688f ("ARM: select PCI_DOMAINS config from
ARCH_MULTIPLATFORM"), so I dropped that.
Arnd
^ permalink raw reply
* [GIT PULL] ARM: at91: drivers for 4.10
From: Arnd Bergmann @ 2016-11-25 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114184438.k5ysd6pgcadlo5vw@piout.net>
On Monday, November 14, 2016 7:44:38 PM CET Alexandre Belloni wrote:
> Drivers for 4.10:
>
> - few fixes for the memory drivers
> - minimal security module driver
> - support for the Secure SRAM
>
For reference, Olof pulled this into next/drivers on Nov 18.
Arnd
^ permalink raw reply
* [PATCH] ARM: ixp4xx: drop duplicate header gpio.h
From: Arnd Bergmann @ 2016-11-25 23:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <319a5803aac795e175306d4978134f0247cf87bc.1479457751.git.geliangtang@gmail.com>
On Friday, November 18, 2016 10:21:10 PM CET Geliang Tang wrote:
> Drop duplicate header gpio.h from dsmg600-setup.c.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
>
Applied to arm-soc/next/fixes-non-critical, thanks
Arnd
^ permalink raw reply
* [PATCH] ARM: lpc32xx: drop duplicate header device.h
From: Arnd Bergmann @ 2016-11-25 23:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479761945.1477.0.camel@localhost>
On Monday, November 21, 2016 3:59:05 PM CET Sylvain Lemieux wrote:
> On Fri, 2016-11-18 at 22:21 +0800, Geliang Tang wrote:
> > Drop duplicate header device.h from phy3250.c.
> >
> > Signed-off-by: Geliang Tang <geliangtang@gmail.com>
> Reviewed-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
>
Applied into arm-soc/next/fixes-non-critical, I see we already merged
your other pull requests, so it seems appropriate to take this
trivial change directly.
Arnd
^ permalink raw reply
* [GIT PULL v2] pxa-dt for v4.10
From: Arnd Bergmann @ 2016-11-25 23:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvgvsspi.fsf@belgarion.home>
On Saturday, November 19, 2016 10:51:37 AM CET Robert Jarzmik wrote:
> This device-tree pxa update brings :
> - pxa25x support
> - cpu operating points in preparation for cpufreq-dt
> - small fixes
>
Pulled into next/dt, thanks for the rework!
Arnd
^ permalink raw reply
* [GIT PULL v2] Qualcomm Device Tree Changes for v4.10
From: Arnd Bergmann @ 2016-11-25 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479535031-14817-1-git-send-email-andy.gross@linaro.org>
On Friday, November 18, 2016 11:57:11 PM CET Andy Gross wrote:
> Qualcomm Device Tree Changes for v4.10 - v2
>
> * Add EBI2 support to MSM8660
> * Add SMSC ethernet support to APQ8060
> * Add support for display, pstore, iommu, and hdmi to APQ8064
> * Add SDHCI node to MSM8974 Hammerhead
> * Add WP8548 MangOH board support (MDM9615)
Thanks for respinning the pull request
> ----------------------------------------------------------------
> Archit Taneja (2):
> arm: dts: qcom: apq8064: Add display DT nodes
> arm: dts: qcom: apq8064-ifc6410: Add HDMI support
>
> Bhushan Shah (1):
> ARM: dts: qcom: msm8974-hammerhead: Add sdhci1 node
>
> John Stultz (3):
> arm: dts: qcom: apq8064: Add dsi, gpu and iommu nodes
> arm: dts: qcom: apq8064-nexus7: Add DSI and panel nodes
> arm: dts: qcom: apq8064-nexus7: Add pstore support to nexus7
I see that some of the subject lines are still not what they
should be, as Archit and John both used 'arm' instead of 'ARM'
as the prefix.
It doesn't seem to justify doing a v3 for that, just watch out
for merges in the future. Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH] ARM: pxa: ezx: fix a910 camera data
From: Stefan Schmidt @ 2016-11-25 23:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87eg1zqqub.fsf@belgarion.home>
Hello.
On 25.11.2016 20:53, Robert Jarzmik wrote:
> Stefan Schmidt <stefan@datenfreihafen.org> writes:
>
>> Hello.
>>
>> On 24.11.2016 17:29, Arnd Bergmann wrote:
>>> The camera_supply_dummy_device definition is shared between a780 and a910,
>>> but only provided when the first is enabled and fails to build for a
>>> configuration with only a910:
>>>
>>> arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)
>>>
>>> This moves the definition into its own section.
>>>
>>> Fixes: 6c1b417adc8f ("ARM: pxa: ezx: use the new pxa_camera platform_data")
>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>> ---
>>> arch/arm/mach-pxa/ezx.c | 56 ++++++++++++++++++++++++++-----------------------
>>
>> I wonder what we should do with ezx.c.
>>
>> As far as I know neither Daniel nor Harald or myself are doing anything
>> with this devices anymore. Besides a basic compile test having an ack or
>> reviewed by from our side is a bit worthless. :/
>>
>> I should still have some of these phones around in a box somewhere. If
>> there is someone with a good motivation and time to take over on this
>> platform we will find a way to get the person this devices.
>>
>> Any takers? Robert? I guess you are already overloaded but you might
>> also have an interest. Worth asking :)
> Oh yes, I'm very interested in your box. Besides I really like old platforms
> :)
Great! I should have at least 3 or 4 different devices from the EZX
platform around. I will go and search for the box over the weekend :)
>> In the case nobody wants to pick up here what would you consider the
>> bets way forward? I could send a patch removing ezx platform support
>> from the kernel (basically ezx.c plus build support) or I can send a
>> patch marking it at least orphan in MAINTAINERS. Let me know what you think.
>>
>> Daniel, Harald, if one of you is still interested in these and what to
>> pick up the work again, please speak up now. :)
> Unless another maintainer steps in, you can submit a patch to transfer the
> maintainance onto me, and we'll see off mailing lists how we could arange the
> boards transfer.
I cc'ed another developer who did a lot of work regarding EZX.
Antonio, as you can see from the mail above we are pondering what who
will maintain the ezx platform in the kernel going forward. Neither
Daniel, Harald or me is going to do so. If you have time, interest and
motivation to do so please speak up. I know life moved on and you ahve
other projects and interests so do not feel pressured here. Just say no
if you have no interest. Robert already agreed to act as a fallback so
we would still be safe. :)
regards
Stefan Schmidt
^ permalink raw reply
* [GIT PULL v2] ARM: OXNAS SoC updates for 4.10
From: Arnd Bergmann @ 2016-11-25 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <55c31b07-ae4e-5bb3-3576-b597805c009d@baylibre.com>
On Wednesday, November 23, 2016 10:01:08 AM CET Neil Armstrong wrote:
> - Add SMP support for the Oxford Semiconductor OX820 SoC
> from http://lkml.kernel.org/r/20161021085848.1754-1-narmstrong at baylibre.com
>
> Changes since v1 Pull Request at : http://lkml.kernel.org/r/1305c61f-b1ef-7caf-7788-67e2b907e873 at baylibre.com
> - Clarify copyright dates in commit message
> - Remove linux/arch/... lines from the top of the files
>
>
Thanks for the v2 update, pulled into next/soc now.
Arnd
^ 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