Hi Nicholas,
[auto build test ERROR on v4.9-rc3]
[also build test ERROR on next-20161028]
[cannot apply to powerpc/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
conven
Hi Nicholas,
[auto build test ERROR on v4.9-rc3]
[also build test ERROR on next-20161028]
[cannot apply to powerpc/next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
conven
On Tue, 1 Nov 2016 15:41:12 +1100
Nicholas Piggin wrote:
> On Tue, 1 Nov 2016 15:22:19 +1100
> Nicholas Piggin wrote:
>
> > The powerpc64 linker generates fpr save/restore functions on-demand,
> > placing them in the .sfpr section. So remove the explicitly coded ones
> > from the 64 build.
> >
The function kvmppc_set_arch_compat() is used to determine the value of the
processor compatibility register (PCR) for a guest running in a given
compatibility mode. There is currently no support for v3.00 of the ISA.
Add support for v3.00 of the ISA which adds an ISA v2.07 compatilibity mode
to t
ISA 3.00 adds the logical PVR value 0x0f05, so add a definition for
this.
Define PCR_ARCH_207 to reflect ISA 2.07 compatibility mode in the processor
compatibility register (PCR). Also define a dummy ISA 3.00 compatibility
mode PCR_ARCH_300 to be used in the next patch to help with determining
Version v3.00 of the ISA added a new compat level to the processor
compatibility register (PCR), an ISA v2.07 compatibility mode.
Upstream QEMU already supports this so it may as well go into the kernel
now.
Change Log:
V1 -> V2:
- Reworked logic to set and mask the PCR, no functional change
V
On Tue, 1 Nov 2016 15:22:19 +1100
Nicholas Piggin wrote:
> The powerpc64 linker generates fpr save/restore functions on-demand,
> placing them in the .sfpr section. So remove the explicitly coded ones
> from the 64 build.
>
> Have 32-bit put save/restore functions into .sfpr section rather than
Sergey Senozhatsky writes:
> On (10/31/16 15:50), Paul Burton wrote:
> [..]
>> Actually whilst this fixes the output in QEMU it has other problems. I'm
>> still
>> digging...
>
> I propose a revert of '05fd007e46296', so you guys can find the
> problem and fix it, not being under 'rc3' pressure.
The powerpc64 linker generates fpr save/restore functions on-demand,
placing them in the .sfpr section. So remove the explicitly coded ones
from the 64 build.
Have 32-bit put save/restore functions into .sfpr section rather than
.text, to match 64-bit.
And explicitly have the linker script place
On Thursday, October 27, 2016 02:05:04 PM Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy"
>
> Hi,
>
> This is the second iteration of the patchset to use the psscr_val and
> psscr_mask provided by the firmware for each of the stop states.
>
> The previous version can be found here:
> http
Hi,
On (10/31/16 15:50), Paul Burton wrote:
[..]
> Actually whilst this fixes the output in QEMU it has other problems. I'm
> still
> digging...
I propose a revert of '05fd007e46296', so you guys can find the
problem and fix it, not being under 'rc3' pressure.
-ss
On Mon, 2016-10-31 at 16:44 +1100, Paul Mackerras wrote:
> On Mon, Oct 31, 2016 at 11:28:23AM +1100, Suraj Jitindar Singh wrote:
> >
> > The function kvmppc_set_arch_compat() is used to determine the
> > value of the
> > processor compatibility register (PCR) for a guest running in a
> > given
> >
On 10/31/2016 06:09 PM, Sergey Senozhatsky wrote:
Hi,
On (10/31/16 15:50), Paul Burton wrote:
[..]
Actually whilst this fixes the output in QEMU it has other problems. I'm still
digging...
I propose a revert of '05fd007e46296', so you guys can find the
problem and fix it, not being under 'rc3
On Mon, 31 Oct 2016, Zubair Lutfullah Kakakhel wrote:
> The drivers read/write function handling is a bit quirky.
Can you please explain in more detail what's quirky and why it should be
done differently,
> And the irqmask is passed directly to the handler.
I can't make any sense out of that se
On 10/31/2016 10:50 AM, Paul Burton wrote:
On Monday, 31 October 2016 12:14:55 GMT Paul Burton wrote:
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device
On Okt 30 2016, Benjamin Herrenschmidt wrote:
> On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
>>
>> Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to
>> commit 05fd007e4629
>> Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne
>> l.org/msg125339
On Sun, Oct 30, 2016 at 6:20 AM, Thorsten Leemhuis
wrote:
>
> Desc: tpm0: TPM self test failed
> Repo: 2016-10-28
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1259943.html
> Stat: 2016-10-28
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1260452.html
> https://
Only s390 and powerpc have hardware facilities allowing to measure
cputimes scaled by frequency. On all other architectures
utimescaled/stimescaled are equal to utime/stime (however they are
accounted separately).
Patch remove {u,s}timescaled accounting on all architectures except
powerpc and s390
On 10/31/2016 07:14 AM, Paul Burton wrote:
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we
On Monday, 31 October 2016 12:14:55 GMT Paul Burton wrote:
> If a device tree specified a preferred device for kernel console output
> via the stdout-path or linux,stdout-path chosen node properties there's
> no guarantee that it will have specified a device for which we have a
> driver. It may als
ord what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Stanislaw-Gruszka/cputime-powerpc-remove-cputime_last_delta-global-variable/20161031-204221
base: ht
Only s390 and powerpc have hardware facilities allowing to measure
cputimes scaled by frequency. On all other architectures
utimescaled/stimescaled are equal to utime/stime (however they are
accounted separately).
Patch remove {u,s}timescaled accounting on all architectures except
powerpc and s390
ord what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Stanislaw-Gruszka/cputime-powerpc-remove-cputime_last_delta-global-variable/20161031-204221
base: ht
Now since fetch_task_cputime() has no other users than task_cputime(),
it's code could be used directly in task_cputime(). Moreover since
only 2 task_cputime() calls of 17 use NULL argument, we can
add dummy variables to those calls and remove NULL checks from
task_cputimes().
Do also remove NULL
Only s390 and powerpc have hardware facilities allowing to measure
cputimes scaled by frequency. On all other architectures
utimescaled/stimescaled are equal to utime/stime (however they are
accounted separately).
Patch remove {u,s}timescaled accounting on all architectures except
powerpc and s390
Currently cputime_to_scaled() just return it's argument on
all implementations, we don't need to call this function.
Signed-off-by: Stanislaw Gruszka
---
arch/powerpc/include/asm/cputime.h|7 ---
include/asm-generic/cputime_jiffies.h |1 -
include/asm-generic/cputime_nsecs.h |
Since commit:
cf9efce0ce313 ("powerpc: Account time using timebase rather than PURR")
cputime_last_delta is not initialized to other value than 0, hence it's
not used except zero check and cputime_to_scaled() just returns
the argument.
Signed-off-by: Stanislaw Gruszka
---
arch/powerpc/include/
Patches remove accounting of utimescaled/stimescaled on architectures
that do not provide those values (scaled cputimes are equal to normal
cputimes) what is every architecture except powerpc and s390.
Patches do not change user visible behaviour.
There is very little documentation how scaled cpu
Hi Michael et al,
On Monday, 31 October 2016 16:28:59 GMT Michael Ellerman wrote:
> Andreas Schwab writes:
> > Any news?
>
> We discovered it also breaks VGA on qemu, which presumably is not the
> type of news you were hoping for.
On the contrary, that's wonderful news - I can test that! Huzzah
The Xilinx interrupt controller driver is now available in drivers/irqchip.
Switch to using that driver.
Signed-off-by: Zubair Lutfullah Kakakhel
Acked-by: Michael Ellerman (powerpc)
---
V5 -> V6 Added Acked-by Micheal Ellerman
V5 New patch
Tested on virtex440-ml507 using qemu
---
arch/power
The powerpc dts file upstream does not have the xlnx,kind-of-intr
property. Instead of erroring out, give a warning instead.
And attempt to continue to probe the interrupt controller while
assuming kind-of-intr is 0x0 as a fall back.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V5 -> V6
Rebase t
The MIPS based xilfpga platform has the following IRQ structure
Peripherals --> xilinx_intcontroller -> mips_cpu_int controller
Add support for the driver to chain the irq handler
Signed-off-by: Zubair Lutfullah Kakakhel
---
V5 -> V6
Use chained_irq_enter and chained_irq_exit
Add error check f
Now that the driver is generic and used by multiple archs,
get_irq is too generic.
Rename get_irq to xintc_get_irq to avoid any conflicts
Signed-off-by: Zubair Lutfullah Kakakhel
---
V5 -> V6
Removed __func__ in printk
Rebase to v4.9-rc3
V4 -> V5
Rebased to v4.9-rc1
Use __func__ in pr_err
V3
The drivers read/write function handling is a bit quirky.
And the irqmask is passed directly to the handler.
Add a new irqchip struct to pass to the handler and
cleanup read/write handling.
Signed-off-by: Zubair Lutfullah Kakakhel
---
V5 -> V6
Removed __func__ from printk
Rebase to v4.9-rc3
V4
The Xilinx AXI Interrupt Controller IP block is used by the MIPS
based xilfpga platform and a few PowerPC based platforms.
Move the interrupt controller code out of arch/microblaze so that
it can be used by everyone
Signed-off-by: Zubair Lutfullah Kakakhel
---
V5 -> V6
Rebase to v4.9-rc3
V4 ->
Hi,
The MIPS based Xilfpga platform uses the Xilinx interrupt controller
daisy chained to the MIPS microAptiv cpu interrupt controller.
This patch series moves the Xilinx interrupt controller driver out
of arch/microblaze to drivers/irqchip and then cleans it up a bit.
And then removes another im
If a device tree specified a preferred device for kernel console output
via the stdout-path or linux,stdout-path chosen node properties there's
no guarantee that it will have specified a device for which we have a
driver. It may also be the case that we do have a driver but it doesn't
call of_conso
Identify the SoC type and revision, and register this information with
the SoC bus, so it is available under /sys/devices/soc0/, and can be
checked where needed using soc_device_match().
Identification is done using the Product Register or Common Chip Code
Register, as declared in DT, or using a h
From: Arnd Bergmann
We keep running into cases where device drivers want to know the exact
version of the a SoC they are currently running on. In the past, this has
usually been done through a vendor specific API that can be called by a
driver, or by directly accessing some kind of version regist
Hi all,
Some Renesas SoCs may exist in different revisions, providing slightly
different functionalities (e.g. R-Car H3 ES1.x and ES2.0), and behavior
(errate and quirks). This needs to be catered for by drivers and/or
platform code. The recently proposed soc_device_match() API seems lik
If soc_device_match() is used to check the value of a specific
attribute that is not present for the current SoC, the kernel crashes
with a NULL pointer dereference.
Fix this by explicitly checking for the absence of a needed property,
and considering this a non-match.
Signed-off-by: Geert Uytter
Provide a dummy implementation of soc_device_match(), to allow compiling
drivers that may be used on SoCs both with and without CONFIG_SOC_BUS,
and for compile testing.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
include/linux/sys_soc.h | 6 ++
1 file changed, 6 insertions(+)
dif
Add a device node for the Product Register, which provides SoC product
and revision information.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/ar
If soc_device_register() is called before soc_bus_register(), it crashes
with a NULL pointer dereference.
soc_bus_register() is already a core_initcall(), but drivers/base/ is
entered later than e.g. drivers/pinctrl/ and drivers/soc/. Hence there
are several subsystems that may need to know SoC re
Add device tree binding documentation for the Common Chip Code Register
and Product Register, which provide SoC product and revision
information.
Signed-off-by: Geert Uytterhoeven
---
v2:
- New.
---
Documentation/devicetree/bindings/arm/shmobile.txt | 26 ++
1 file changed,
Now that usb_endpoint_maxp() only returns the lowest
11 bits from wMaxPacketSize, we can remove the &
operation from this driver.
Cc: Li Yang
Cc:
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/fsl_udc_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/fsl_
We have introduced a helper to calculate multiplier
value from wMaxPacketSize. Start using it.
Cc: Li Yang
Cc:
Signed-off-by: Felipe Balbi
---
drivers/usb/gadget/udc/fsl_udc_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c
b/driv
Andrew Donnellan writes:
> On 31/10/16 08:34, Christophe JAILLET wrote:
>> 'cxl_dev_context_init()' returns an error pointer in case of error, not
>> NULL. So test it with IS_ERR.
>>
>> Signed-off-by: Christophe JAILLET
>
> Reviewed-by: Andrew Donnellan
>
>> ---
>> un-compiled because I don't h
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, October 28, 2016 6:54 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, October 28, 2016 6:53 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i...
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, October 28, 2016 6:48 PM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Y.B. Lu; linux-...@vger.kernel.org; ulf.hans...@linaro.org; Scott
> Wood; Mark Rutland; Greg Kroah-Hartman; X.B. Xie; M.H. Lian; linux-
> i...
51 matches
Mail list logo