* [PATCH v2] powerpc 8xx: defconfig: slice by 4 is more efficient than the default slice by 8 on Powerpc 8xx.
From: Christophe Leroy @ 2013-11-22 17:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras
Cc: scottwood, linuxppc-dev, linux-kernel
On PPC_8xx, CRC32_SLICEBY4 is more efficient (almost twice) than CRC32_SLICEBY8,
as shown below:
With CRC32_SLICEBY8:
[ 1.109204] crc32: CRC_LE_BITS = 64, CRC_BE BITS = 64
[ 1.114401] crc32: self tests passed, processed 225944 bytes in 15118910 nsec
[ 1.130655] crc32c: CRC_LE_BITS = 64
[ 1.134235] crc32c: self tests passed, processed 225944 bytes in 4479879 nsec
With CRC32_SLICEBY4:
[ 1.097129] crc32: CRC_LE_BITS = 32, CRC_BE BITS = 32
[ 1.101878] crc32: self tests passed, processed 225944 bytes in 8616242 nsec
[ 1.116298] crc32c: CRC_LE_BITS = 32
[ 1.119607] crc32c: self tests passed, processed 225944 bytes in 3289576 nsec
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
diff -ur a/arch/powerpc/configs/adder875_defconfig b/arch/powerpc/configs.new/adder875_defconfig
--- a/arch/powerpc/configs/adder875_defconfig 2013-11-22 18:20:10.342968268 +0100
+++ b/arch/powerpc/configs.new/adder875_defconfig 2013-11-22 18:17:46.499686457 +0100
@@ -70,3 +70,4 @@
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_CRC32_SLICEBY4=y
diff -ur a/arch/powerpc/configs/ep88xc_defconfig b/arch/powerpc/configs.new/ep88xc_defconfig
--- a/arch/powerpc/configs/ep88xc_defconfig 2013-11-22 18:20:10.286961148 +0100
+++ b/arch/powerpc/configs.new/ep88xc_defconfig 2013-11-22 18:17:41.992113565 +0100
@@ -72,3 +72,4 @@
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_CRC32_SLICEBY4=y
diff -ur a/arch/powerpc/configs/mpc866_ads_defconfig b/arch/powerpc/configs.new/mpc866_ads_defconfig
--- a/arch/powerpc/configs/mpc866_ads_defconfig 2013-11-22 18:20:10.323965853 +0100
+++ b/arch/powerpc/configs.new/mpc866_ads_defconfig 2013-11-22 18:17:32.480904735 +0100
@@ -55,3 +55,4 @@
CONFIG_CRC_CCITT=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_CRYPTO_ANSI_CPRNG is not set
+CONFIG_CRC32_SLICEBY4=y
diff -ur a/arch/powerpc/configs/mpc885_ads_defconfig b/arch/powerpc/configs.new/mpc885_ads_defconfig
--- a/arch/powerpc/configs/mpc885_ads_defconfig 2013-11-22 18:20:10.326966235 +0100
+++ b/arch/powerpc/configs.new/mpc885_ads_defconfig 2013-11-22 18:17:25.760050546 +0100
@@ -78,3 +78,4 @@
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_CRC32_SLICEBY4=y
diff -ur a/arch/powerpc/configs/tqm8xx_defconfig b/arch/powerpc/configs.new/tqm8xx_defconfig
--- a/arch/powerpc/configs/tqm8xx_defconfig 2013-11-22 18:20:10.317965090 +0100
+++ b/arch/powerpc/configs.new/tqm8xx_defconfig 2013-11-22 18:17:14.926673681 +0100
@@ -84,3 +84,4 @@
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEBUG_INFO=y
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
+CONFIG_CRC32_SLICEBY4=y
^ permalink raw reply
* Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Scott Wood @ 2013-11-22 18:39 UTC (permalink / raw)
To: Liu Gang; +Cc: b07421, linus.walleij, r61911, linux-gpio, agust, linuxppc-dev
In-Reply-To: <1385107960-373-1-git-send-email-Gang.Liu@freescale.com>
On Fri, 2013-11-22 at 16:12 +0800, Liu Gang wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But the code may give the
> wrong status of GPIOs defined as input under some scenarios:
>
> 1. If some pins were configured as inputs and were asserted
> high before booting the kernel, the shadow data has been
> initialized with those pin values.
> 2. Some pins have been configured as output first and have
> been set to the high value, then reconfigured as input.
>
> The above cases will make the shadow data for those input
> pins to be set to high. Then reading the pin status will
> always return high even if the actual pin status is low.
>
> The code should eliminate the effects of the shadow data to
> the input pins, and the status of those pins should be
> read directly from GPDAT.
>
> Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
> ---
> changes in v2:
> - Added more description of the problem.
> - Reduced one in_be32() call.
> - Do not modify the shadow data.
>
> drivers/gpio/gpio-mpc8xxx.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 914e859..d7d6d72 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> u32 val;
> struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc);
> struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm);
> + u32 out_mask, out_shadow;
>
> - val = in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + GPIO_DIR);
> + out_mask = in_be32(mm->regs + GPIO_DIR);
>
> - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> + val = in_be32(mm->regs + GPIO_DAT) & ~out_mask;
> + out_shadow = mpc8xxx_gc->data & out_mask;
> +
> + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio);
> }
>
> static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
Acked-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
From: Kumar Gala @ 2013-11-22 20:51 UTC (permalink / raw)
To: Liu Gang; +Cc: b07421, linus.walleij, r61911, linux-gpio, agust, linuxppc-dev
In-Reply-To: <1385107960-373-1-git-send-email-Gang.Liu@freescale.com>
On Nov 22, 2013, at 2:12 AM, Liu Gang <Gang.Liu@freescale.com> wrote:
> For MPC8572/MPC8536, the status of GPIOs defined as output
> cannot be determined by reading GPDAT register, so the code
> use shadow data register instead. But the code may give the
> wrong status of GPIOs defined as input under some scenarios:
>=20
> 1. If some pins were configured as inputs and were asserted
> high before booting the kernel, the shadow data has been
> initialized with those pin values.
> 2. Some pins have been configured as output first and have
> been set to the high value, then reconfigured as input.
>=20
> The above cases will make the shadow data for those input
> pins to be set to high. Then reading the pin status will
> always return high even if the actual pin status is low.
>=20
> The code should eliminate the effects of the shadow data to
> the input pins, and the status of those pins should be
> read directly from GPDAT.
>=20
> Signed-off-by: Liu Gang <Gang.Liu@freescale.com>
> ---
> changes in v2:
> - Added more description of the problem.
> - Reduced one in_be32() call.
> - Do not modify the shadow data.
>=20
> drivers/gpio/gpio-mpc8xxx.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>=20
> diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c
> index 914e859..d7d6d72 100644
> --- a/drivers/gpio/gpio-mpc8xxx.c
> +++ b/drivers/gpio/gpio-mpc8xxx.c
> @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, =
unsigned int gpio)
> u32 val;
> struct of_mm_gpio_chip *mm =3D to_of_mm_gpio_chip(gc);
> struct mpc8xxx_gpio_chip *mpc8xxx_gc =3D =
to_mpc8xxx_gpio_chip(mm);
> + u32 out_mask, out_shadow;
>=20
> - val =3D in_be32(mm->regs + GPIO_DAT) & ~in_be32(mm->regs + =
GPIO_DIR);
> + out_mask =3D in_be32(mm->regs + GPIO_DIR);
>=20
> - return (val | mpc8xxx_gc->data) & mpc8xxx_gpio2mask(gpio);
> + val =3D in_be32(mm->regs + GPIO_DAT) & ~out_mask;
> + out_shadow =3D mpc8xxx_gc->data & out_mask;
> +
> + return (val | out_shadow) & mpc8xxx_gpio2mask(gpio);
> }
I really think a comment is worth adding here about why we do this.
- k
>=20
> static int mpc8xxx_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> --=20
> 1.8.4.1
>=20
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Windfarm's max6690 sensor driver was not included in makefile
From: Stanislav Ponomarev @ 2013-11-22 21:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 1042 bytes --]
Hello, I had problems with fan speed in my XServe G5. It turned out
drivers/macintosh/Makefile has a max6690 module missing from compilation
list. I was advised to mail the patch to you guys.
I'm not sure what's the proper format of the patch to be submitten (this is
my first time). So I'm including it into the message body, and as an
attached file.
diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
index 6753b65..d2f0120 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_WINDFARM_RM31) +=
windfarm_fcu_controls.o \
windfarm_ad7417_sensor.o \
windfarm_lm75_sensor.o \
windfarm_lm87_sensor.o \
+ windfarm_max6690_sensor.o \
windfarm_pid.o \
windfarm_cpufreq_clamp.o \
windfarm_rm31.o
Thank you.
Stanislav Ponomarev.
[-- Attachment #1.2: Type: text/html, Size: 1189 bytes --]
[-- Attachment #2: Makefile.patch --]
[-- Type: text/x-patch, Size: 585 bytes --]
index 6753b65..d2f0120 100644
--- a/drivers/macintosh/Makefile
+++ b/drivers/macintosh/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_WINDFARM_RM31) += windfarm_fcu_controls.o \
windfarm_ad7417_sensor.o \
windfarm_lm75_sensor.o \
windfarm_lm87_sensor.o \
+ windfarm_max6690_sensor.o \
windfarm_pid.o \
windfarm_cpufreq_clamp.o \
windfarm_rm31.o
^ permalink raw reply related
* Re: [PATCH 1/8] IBM Akebono: Add support to AHCI platform driver
From: Tejun Heo @ 2013-11-22 22:24 UTC (permalink / raw)
To: Alistair Popple; +Cc: linux-ide, linuxppc-dev
In-Reply-To: <1385086116-10972-1-git-send-email-alistair@popple.id.au>
Hello,
On Thu, Nov 21, 2013 at 9:08 PM, Alistair Popple <alistair@popple.id.au> wrote:
> The new IBM Akebono board has a PPC476GTR SoC with an AHCI compliant
> SATA controller. This patch adds a compatible property for the new SoC
> to the AHCI platform driver.
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
Applied to libata/for-3.13-fixes w/ stable cc'd.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Scott Wood @ 2013-11-22 22:34 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: Liu Yu, linuxppc-dev, linux-kernel, Shan Hai
In-Reply-To: <Pine.LNX.4.64.1311041651390.4290@digraph.polyomino.org.uk>
On Mon, 2013-11-04 at 16:52 +0000, Joseph S. Myers wrote:
> From: Joseph Myers <joseph@codesourcery.com>
>
> The e500 SPE floating-point emulation code clears existing exceptions
> (__FPU_FPSCR &= ~FP_EX_MASK;) before ORing in the exceptions from the
> emulated operation. However, these exception bits are the "sticky",
> cumulative exception bits, and should only be cleared by the user
> program setting SPEFSCR, not implicitly by any floating-point
> instruction (whether executed purely by the hardware or emulated).
> The spurious clearing of these bits shows up as missing exceptions in
> glibc testing.
>
> Fixing this, however, is not as simple as just not clearing the bits,
> because while the bits may be from previous floating-point operations
> (in which case they should not be cleared), the processor can also set
> the sticky bits itself before the interrupt for an exception occurs,
> and this can happen in cases when IEEE 754 semantics are that the
> sticky bit should not be set. Specifically, the "invalid" sticky bit
> is set in various cases with non-finite operands, where IEEE 754
> semantics do not involve raising such an exception, and the
> "underflow" sticky bit is set in cases of exact underflow, whereas
> IEEE 754 semantics are that this flag is set only for inexact
> underflow. Thus, for correct emulation the kernel needs to know the
> setting of these two sticky bits before the instruction being
> emulated.
>
> When a floating-point operation raises an exception, the kernel can
> note the state of the sticky bits immediately afterwards. Some
> <fenv.h> functions that affect the state of these bits, such as
> fesetenv and feholdexcept, need to use prctl with PR_GET_FPEXC and
> PR_SET_FPEXC anyway, and so it is natural to record the state of those
> bits during that call into the kernel and so avoid any need for a
> separate call into the kernel to inform it of a change to those bits.
> Thus, the interface I chose to use (in this patch and the glibc port)
> is that one of those prctl calls must be made after any userspace
> change to those sticky bits, other than through a floating-point
> operation that traps into the kernel anyway.
This sounds like an incompatible change to userspace API. What about
older glibc? What about user code that directly manipulates these bits
rather than going through libc, or uses a libc other than glibc? Where
is this API requirement documented?
I think the impact of this could be reduced by using this mechanism only
to clear bits, rather than set them. That is, if the exception bit is
unset, don't set it just because it's set in spefscr_last -- but if it's
not set in spefscr_last, and the emulation code doesn't want to set it,
then clear it.
Are there any cases where the exception bit can be set without the
kernel taking a trap, or is userspace manipulation limited to clearing
the bits?
-Scott
^ permalink raw reply
* Pull request: scottwood/linux.git
From: Scott Wood @ 2013-11-22 23:21 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The corenet64 patch fixes a regression introduced in 3.13-rc1 (commit
ef1313deafb7baa6d3382044e962d5ad5e8c8dd6, "powerpc: Add VMX optimised xor
for RAID5").
The 8xx patch fixes a regression introduced in 3.12 (commit
beb2dc0a7a84be003ce54e98b95d65cc66e6e536, "powerpc: Convert some
mftb/mftbu into mfspr").
The other two patches are fixes for minor, long standing bugs.
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/scottwood/linux.git
for you to fetch changes up to d742aa152f27448d39ce65fb829e396d10cd63a9:
powerpc/booke: Only check for hugetlb in flush if vma != NULL (2013-11-22 16:57:29 -0600)
----------------------------------------------------------------
Adam Borowski (1):
powerpc/85xx: typo in dts: "interupt" (four devices)
LEROY Christophe (1):
powerpc/8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supported
Scott Wood (1):
powerpc/booke: Only check for hugetlb in flush if vma != NULL
Tiejun Chen (1):
powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well
arch/powerpc/Makefile | 5 +++++
arch/powerpc/boot/dts/xcalibur1501.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
arch/powerpc/boot/util.S | 14 ++++++++++++++
arch/powerpc/include/asm/ppc_asm.h | 2 ++
arch/powerpc/include/asm/reg.h | 7 +++++++
arch/powerpc/include/asm/timex.h | 8 ++++++++
arch/powerpc/kernel/vdso32/gettimeofday.S | 6 ++++++
arch/powerpc/mm/hugetlbpage-book3e.c | 3 +--
arch/powerpc/mm/tlb_nohash.c | 2 +-
12 files changed, 52 insertions(+), 11 deletions(-)
^ permalink raw reply
* eth0: hw csum failure
From: Andreas Schwab @ 2013-11-23 0:44 UTC (permalink / raw)
To: linuxppc-dev
I get a lot of "eth0: hw csum failure" with 3.13-rc1 on my G5.
eth0: hw csum failure
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1 #1
Call Trace:
[c00000000ffef1d0] [c00000000000f97c] .show_stack+0x60/0x14c (unreliable)
[c00000000ffef2a0] [c00000000069fad8] .dump_stack+0x80/0xa0
[c00000000ffef320] [c000000000552bc0] .netdev_rx_csum_fault+0x4c/0x58
[c00000000ffef3a0] [c000000000546f88] .__skb_checksum_complete_head+0x54/0x78
[c00000000ffef420] [c0000000005f1118] .nf_ip_checksum+0xf4/0x100
[c00000000ffef4b0] [c00000000058e520] .udp_error+0x198/0x210
[c00000000ffef560] [c000000000587694] .nf_conntrack_in+0x14c/0xa20
[c00000000ffef690] [c0000000005f195c] .ipv4_conntrack_in+0x24/0x38
[c00000000ffef700] [c00000000058343c] .nf_iterate+0x64/0xb4
[c00000000ffef7c0] [c00000000058353c] .nf_hook_slow+0xb0/0x188
[c00000000ffef890] [c00000000059ea9c] .ip_rcv+0x390/0x3f0
[c00000000ffef930] [c000000000551578] .__netif_receive_skb_core+0x8c4/0x964
[c00000000ffefa30] [c000000000551c38] .netif_receive_skb+0xb0/0x130
[c00000000ffefae0] [c000000000552740] .napi_gro_receive+0x50/0xc0
[c00000000ffefb60] [c000000000447754] .gem_poll+0x10f0/0x1328
[c00000000ffefcc0] [c000000000552418] .net_rx_action+0xd8/0x240
[c00000000ffefd90] [c00000000004dfc4] .__do_softirq+0x158/0x2c0
[c00000000ffefea0] [c00000000004e448] .irq_exit+0x6c/0xc4
[c00000000ffeff10] [c00000000000ce14] .__do_irq+0xec/0xf8
[c00000000ffeff90] [c000000000019474] .call_do_irq+0x14/0x24
[c0000001f615ba30] [c00000000000cea0] .do_IRQ+0x80/0xc0
[c0000001f615bac0] [c0000000000024b8] hardware_interrupt_common+0x138/0x180
--- Exception: 501 at .arch_cpu_idle+0x78/0x124
LR = .arch_cpu_idle+0x78/0x124
[c0000001f615bdb0] [c0000000000a3af4] .rcu_idle_enter+0x98/0xb8 (unreliable)
[c0000001f615be30] [c00000000009a978] .cpu_startup_entry+0x110/0x1a0
[c0000001f615bee0] [c00000000001f14c] .start_secondary+0x288/0x290
[c0000001f615bf90] [c0000000000087fc] .start_secondary_prolog+0x10/0x14
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/6] powerpc: fix exception clearing in e500 SPE float emulation
From: Joseph S. Myers @ 2013-11-23 1:22 UTC (permalink / raw)
To: Scott Wood; +Cc: Liu Yu, linuxppc-dev, linux-kernel, Shan Hai
In-Reply-To: <1385159644.1403.532.camel@snotra.buserror.net>
On Fri, 22 Nov 2013, Scott Wood wrote:
> This sounds like an incompatible change to userspace API. What about
> older glibc? What about user code that directly manipulates these bits
> rather than going through libc, or uses a libc other than glibc? Where
> is this API requirement documented?
The previous EGLIBC port, and the uClibc code copied from it, is
fundamentally broken as regards any use of prctl for floating-point
exceptions because it didn't use the PR_FP_EXC_SW_ENABLE bit in its prctl
calls (and did various worse things, such as passing a pointer when prctl
expected an integer). If you avoid anything where prctl is used, the
clearing of sticky bits still means it will never give anything
approximating correct exception semantics with existing kernels. I don't
believe the patch makes things any worse for existing code that doesn't
try to inform the kernel of changes to sticky bits - such code may get
incorrect exceptions in some cases, but it would have done so anyway in
other cases.
This is the best API I could come up with to fix the fundamentally broken
nature of what came before, taking into account that in many cases a prctl
call is already needed along with userspace manipulation of exception
bits. I'm not aware of any kernel documentation where this sort of
subarchitecture-specific API detail is documented. (The API also includes
such things as needing to leave the spefscr trap-enable bits set and use
prctl to control whether SIGFPE results from exceptions.)
> I think the impact of this could be reduced by using this mechanism only
> to clear bits, rather than set them. That is, if the exception bit is
> unset, don't set it just because it's set in spefscr_last -- but if it's
> not set in spefscr_last, and the emulation code doesn't want to set it,
> then clear it.
It should already be the case in this patch that if a bit is clear in
spefscr, and set in spefscr_last (i.e. userspace did not inform the kernel
of clearing the bit, and no traps since then have resulted in the kernel
noticing it was cleared), it won't get set unless the emulation code wants
to set it. The sole place spefscr_last is read is in the statement
"__FPU_FPSCR &= ~(FP_EX_INVALID | FP_EX_UNDERFLOW) |
current->thread.spefscr_last;" - if the bit is already clear in spefscr,
this statement has no effect on it.
> Are there any cases where the exception bit can be set without the
> kernel taking a trap, or is userspace manipulation limited to clearing
> the bits?
Userspace can both set and clear the bits without a trap. For example,
fesetenv restores a saved value of spefscr which may both set and clear
bits (and then it calls prctl because it needs to do so anyway to restore
the saved state for which exceptions were enabled). fesetexceptflag
restores saved state of particular exceptions without a trap (so needs to
call prctl specially to inform the kernel of a change).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply
* [RFC,PATCH] powerpc/powernv: Add iommu DMA bypass support for IODA2
From: Benjamin Herrenschmidt @ 2013-11-23 8:36 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Anton Blanchard
This patch adds the support for to create a direct iommu "bypass"
window on IODA2 bridges (such as Power8) allowing to bypass iommu
page translation completely for 64-bit DMA capable devices.
This is currently enabled unconditionally for any 64-bit device,
we *may* want to make it conditional to a command line argument.
Additionally, this adds a hook to the struct iommu_table so that
the IOMMU API / VFIO can disable the bypass when external ownership
is requested, since in that case, the device will be used by an
environment such as userspace or a KVM guest which must not be
allowed to bypass translations.
It should be possible to do something similar for IODA1 (Power7)
though not all versions of OPALv2/v3 out there support that properly
so for now I won't bother.
Not-yet-signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index e27e9ad..150866b 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -134,6 +134,7 @@ static inline int dma_supported(struct device *dev, u64 mask)
}
extern int dma_set_mask(struct device *dev, u64 dma_mask);
+extern int __dma_set_mask(struct device *dev, u64 dma_mask);
#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index c34656a..ed2e582 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -79,6 +79,7 @@ struct iommu_table {
#ifdef CONFIG_IOMMU_API
struct iommu_group *it_group;
#endif
+ void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
struct scatterlist;
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 8032b97..ee78f6e 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -191,12 +191,10 @@ EXPORT_SYMBOL(dma_direct_ops);
#define PREALLOC_DMA_DEBUG_ENTRIES (1 << 16)
-int dma_set_mask(struct device *dev, u64 dma_mask)
+int __dma_set_mask(struct device *dev, u64 dma_mask)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (ppc_md.dma_set_mask)
- return ppc_md.dma_set_mask(dev, dma_mask);
if ((dma_ops != NULL) && (dma_ops->set_dma_mask != NULL))
return dma_ops->set_dma_mask(dev, dma_mask);
if (!dev->dma_mask || !dma_supported(dev, dma_mask))
@@ -204,6 +202,12 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
*dev->dma_mask = dma_mask;
return 0;
}
+int dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ if (ppc_md.dma_set_mask)
+ return ppc_md.dma_set_mask(dev, dma_mask);
+ return __dma_set_mask(dev, dma_mask);
+}
EXPORT_SYMBOL(dma_set_mask);
u64 dma_get_required_mask(struct device *dev)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 084cdfa..0425a2e 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -21,6 +21,7 @@
#include <linux/irq.h>
#include <linux/io.h>
#include <linux/msi.h>
+#include <linux/memblock.h>
#include <asm/sections.h>
#include <asm/io.h>
@@ -460,7 +461,38 @@ static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev
return;
pe = &phb->ioda.pe_array[pdn->pe_number];
- set_iommu_table_base(&pdev->dev, &pe->tce32_table);
+ if (get_dma_ops(&pdev->dev) == &dma_direct_ops)
+ set_dma_offset(&pdev->dev, pe->tce_bypass_base);
+ else
+ set_iommu_table_base(&pdev->dev, &pe->tce32_table);
+}
+
+static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
+ struct pci_dev *pdev, u64 dma_mask)
+{
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ struct pnv_ioda_pe *pe;
+ uint64_t top;
+ bool bypass = false;
+
+ if (!WARN_ON(!pdn || pdn->pe_number == IODA_INVALID_PE)) {
+ pe = &phb->ioda.pe_array[pdn->pe_number];
+ if (pe->tce_bypass_enabled) {
+ top = pe->tce_bypass_base + memblock_end_of_DRAM() - 1;
+ bypass = (dma_mask >= top);
+ }
+ }
+
+ if (bypass) {
+ dev_info(&pdev->dev, "Using 64-bit DMA iommu bypass\n");
+ set_dma_ops(&pdev->dev, &dma_direct_ops);
+ } else {
+ dev_info(&pdev->dev, "Using 32-bit DMA via iommu\n");
+ set_dma_ops(&pdev->dev, &dma_iommu_ops);
+ }
+ pnv_pci_ioda_dma_dev_setup(phb, pdev);
+
+ return 0;
}
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
@@ -657,6 +689,56 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
}
+static void pnv_pci_ioda2_set_bypass(struct iommu_table *tbl, bool enable)
+{
+ struct pnv_ioda_pe *pe = container_of(tbl, struct pnv_ioda_pe,
+ tce32_table);
+ uint16_t window_id = (pe->pe_number << 1 ) + 1;
+ int64_t rc;
+
+ pe_info(pe, "%sabling 64-bit DMA bypass\n", enable ? "En" : "Dis");
+ if (enable) {
+ phys_addr_t top = memblock_end_of_DRAM();
+
+ top = roundup_pow_of_two(top);
+ rc = opal_pci_map_pe_dma_window_real(pe->phb->opal_id,
+ pe->pe_number,
+ window_id,
+ pe->tce_bypass_base,
+ top);
+ } else {
+ rc = opal_pci_map_pe_dma_window_real(pe->phb->opal_id,
+ pe->pe_number,
+ window_id,
+ pe->tce_bypass_base,
+ 0);
+
+ /*
+ * We might want to reset the DMA ops of all devices on
+ * this PE. However in theory, that shouldn't be necessary
+ * as this is used for VFIO/KVM pass-through and the device
+ * hasn't yet been returned to its kernel driver
+ */
+ }
+ if (rc)
+ pe_err(pe, "OPAL error %lld configuring bypass window\n", rc);
+ else
+ pe->tce_bypass_enabled = enable;
+}
+
+static void pnv_pci_ioda2_setup_bypass_pe(struct pnv_phb *phb,
+ struct pnv_ioda_pe *pe)
+{
+ /* TVE #1 is selected by PCI address bit 59 */
+ pe->tce_bypass_base = 1ull << 59;
+
+ /* Install set_bypass callback for VFIO */
+ pe->tce32_table.set_bypass = pnv_pci_ioda2_set_bypass;
+
+ /* Enable bypass by default */
+ pnv_pci_ioda2_set_bypass(&pe->tce32_table, true);
+}
+
static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
{
@@ -726,6 +808,8 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
else
pnv_ioda_setup_bus_dma(pe, pe->pbus);
+ /* Also create a bypass window */
+ pnv_pci_ioda2_setup_bypass_pe(phb, pe);
return;
fail:
if (pe->tce32_seg >= 0)
@@ -1286,6 +1370,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
/* Setup TCEs */
phb->dma_dev_setup = pnv_pci_ioda_dma_dev_setup;
+ phb->dma_set_mask = pnv_pci_ioda_dma_set_mask;
/* Setup shutdown function for kexec */
phb->shutdown = pnv_pci_ioda_shutdown;
diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
index 4eb33a9..e96af77 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -553,6 +553,16 @@ static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
pnv_pci_dma_fallback_setup(hose, pdev);
}
+int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask)
+{
+ struct pci_controller *hose = pci_bus_to_host(pdev->bus);
+ struct pnv_phb *phb = hose->private_data;
+
+ if (phb && phb->dma_set_mask)
+ return phb->dma_set_mask(phb, pdev, dma_mask);
+ return __dma_set_mask(&pdev->dev, dma_mask);
+}
+
void pnv_pci_shutdown(void)
{
struct pci_controller *hose;
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 911c24e..62ac4ef 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -54,7 +54,9 @@ struct pnv_ioda_pe {
struct iommu_table tce32_table;
phys_addr_t tce_inval_reg_phys;
- /* XXX TODO: Add support for additional 64-bit iommus */
+ /* 64-bit TCE bypass region */
+ bool tce_bypass_enabled;
+ uint64_t tce_bypass_base;
/* MSIs. MVE index is identical for for 32 and 64 bit MSI
* and -1 if not supported. (It's actually identical to the
@@ -113,6 +115,8 @@ struct pnv_phb {
unsigned int hwirq, unsigned int virq,
unsigned int is_64, struct msi_msg *msg);
void (*dma_dev_setup)(struct pnv_phb *phb, struct pci_dev *pdev);
+ int (*dma_set_mask)(struct pnv_phb *phb, struct pci_dev *pdev,
+ u64 dma_mask);
void (*fixup_phb)(struct pci_controller *hose);
u32 (*bdfn_to_pe)(struct pnv_phb *phb, struct pci_bus *bus, u32 devfn);
void (*shutdown)(struct pnv_phb *phb);
diff --git a/arch/powerpc/platforms/powernv/powernv.h b/arch/powerpc/platforms/powernv/powernv.h
index de6819b..213887a 100644
--- a/arch/powerpc/platforms/powernv/powernv.h
+++ b/arch/powerpc/platforms/powernv/powernv.h
@@ -7,12 +7,16 @@ extern void pnv_smp_init(void);
static inline void pnv_smp_init(void) { }
#endif
+struct pci_dev;
+
#ifdef CONFIG_PCI
extern void pnv_pci_init(void);
extern void pnv_pci_shutdown(void);
+extern int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask);
#else
static inline void pnv_pci_init(void) { }
static inline void pnv_pci_shutdown(void) { }
+static inline int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64 dma_mask) { }
#endif
extern void pnv_lpc_init(void);
diff --git a/arch/powerpc/platforms/powernv/setup.c b/arch/powerpc/platforms/powernv/setup.c
index 19884b2..f519f55 100644
--- a/arch/powerpc/platforms/powernv/setup.c
+++ b/arch/powerpc/platforms/powernv/setup.c
@@ -26,6 +26,7 @@
#include <linux/of_fdt.h>
#include <linux/interrupt.h>
#include <linux/bug.h>
+#include <linux/pci.h>
#include <asm/machdep.h>
#include <asm/firmware.h>
@@ -140,6 +141,13 @@ static void pnv_progress(char *s, unsigned short hex)
{
}
+static int pnv_dma_set_mask(struct device *dev, u64 dma_mask)
+{
+ if (dev_is_pci(dev))
+ return pnv_pci_dma_set_mask(to_pci_dev(dev), dma_mask);
+ return __dma_set_mask(dev, dma_mask);
+}
+
static void pnv_shutdown(void)
{
/* Let the PCI code clear up IODA tables */
@@ -223,6 +231,7 @@ define_machine(powernv) {
.show_cpuinfo = pnv_show_cpuinfo,
.progress = pnv_progress,
.machine_shutdown = pnv_shutdown,
+ .dma_set_mask = pnv_dma_set_mask,
.power_save = power7_idle,
.calibrate_decr = generic_calibrate_decr,
#ifdef CONFIG_KEXEC
^ permalink raw reply related
* Re: [PATCH v2] offb: make the screen properties endian safe
From: Cedric Le Goater @ 2013-11-23 17:38 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1385063848.4882.6.camel@pasglop>
On 11/21/2013 08:57 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-11-21 at 16:45 +0100, Cedric Le Goater wrote:
>>> - fbdev *generally* assume native endian framebuffer, but of course
>>> under qemu today, the adapter will use a big endian frame buffer
>>> aperture. You can compile in support for foreign endian but I don't know
>>> how that actually works.
>>
>> OK. I will see how I can extend the tests. But, are you suggesting I should
>> be using the foreign endian framework for the frame buffer ?
>
> Well, if it works ... did you try 16 and 32bpp ?
So, 32bpp "works" but 16 is broken ... I guess my palette fix is just a lucky
hack and I need to dig deeper in fb code to have a better understanding of
the color map.
I should have provided you two patches in the first place. Do you want the
device tree data fixes for the frame buffer screen properties ? It helps to
have a display for little endian guests even if the colors are wrong.
Thanks,
C.
^ permalink raw reply
* Re: [PATCH v2] offb: make the screen properties endian safe
From: Benjamin Herrenschmidt @ 2013-11-23 21:04 UTC (permalink / raw)
To: Cedric Le Goater; +Cc: linuxppc-dev
In-Reply-To: <5290E820.2080809@fr.ibm.com>
On Sat, 2013-11-23 at 18:38 +0100, Cedric Le Goater wrote:
> So, 32bpp "works" but 16 is broken ... I guess my palette fix is just a lucky
> hack and I need to dig deeper in fb code to have a better understanding of
> the color map.
>
> I should have provided you two patches in the first place. Do you want the
> device tree data fixes for the frame buffer screen properties ? It helps to
> have a display for little endian guests even if the colors are wrong.
Before you pull your hair out, check if it works in BE :-)
Cheers,
Ben.
^ permalink raw reply
* Re: eth0: hw csum failure
From: Benjamin Herrenschmidt @ 2013-11-23 21:17 UTC (permalink / raw)
To: Andreas Schwab; +Cc: linuxppc-dev
In-Reply-To: <87d2ls54mn.fsf@igel.home>
On Sat, 2013-11-23 at 01:44 +0100, Andreas Schwab wrote:
> I get a lot of "eth0: hw csum failure" with 3.13-rc1 on my G5.
Alex Graf already reported that, we're looking into it.
Cheers,
Ben.
> eth0: hw csum failure
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1 #1
> Call Trace:
> [c00000000ffef1d0] [c00000000000f97c] .show_stack+0x60/0x14c (unreliable)
> [c00000000ffef2a0] [c00000000069fad8] .dump_stack+0x80/0xa0
> [c00000000ffef320] [c000000000552bc0] .netdev_rx_csum_fault+0x4c/0x58
> [c00000000ffef3a0] [c000000000546f88] .__skb_checksum_complete_head+0x54/0x78
> [c00000000ffef420] [c0000000005f1118] .nf_ip_checksum+0xf4/0x100
> [c00000000ffef4b0] [c00000000058e520] .udp_error+0x198/0x210
> [c00000000ffef560] [c000000000587694] .nf_conntrack_in+0x14c/0xa20
> [c00000000ffef690] [c0000000005f195c] .ipv4_conntrack_in+0x24/0x38
> [c00000000ffef700] [c00000000058343c] .nf_iterate+0x64/0xb4
> [c00000000ffef7c0] [c00000000058353c] .nf_hook_slow+0xb0/0x188
> [c00000000ffef890] [c00000000059ea9c] .ip_rcv+0x390/0x3f0
> [c00000000ffef930] [c000000000551578] .__netif_receive_skb_core+0x8c4/0x964
> [c00000000ffefa30] [c000000000551c38] .netif_receive_skb+0xb0/0x130
> [c00000000ffefae0] [c000000000552740] .napi_gro_receive+0x50/0xc0
> [c00000000ffefb60] [c000000000447754] .gem_poll+0x10f0/0x1328
> [c00000000ffefcc0] [c000000000552418] .net_rx_action+0xd8/0x240
> [c00000000ffefd90] [c00000000004dfc4] .__do_softirq+0x158/0x2c0
> [c00000000ffefea0] [c00000000004e448] .irq_exit+0x6c/0xc4
> [c00000000ffeff10] [c00000000000ce14] .__do_irq+0xec/0xf8
> [c00000000ffeff90] [c000000000019474] .call_do_irq+0x14/0x24
> [c0000001f615ba30] [c00000000000cea0] .do_IRQ+0x80/0xc0
> [c0000001f615bac0] [c0000000000024b8] hardware_interrupt_common+0x138/0x180
> --- Exception: 501 at .arch_cpu_idle+0x78/0x124
> LR = .arch_cpu_idle+0x78/0x124
> [c0000001f615bdb0] [c0000000000a3af4] .rcu_idle_enter+0x98/0xb8 (unreliable)
> [c0000001f615be30] [c00000000009a978] .cpu_startup_entry+0x110/0x1a0
> [c0000001f615bee0] [c00000000001f14c] .start_secondary+0x288/0x290
> [c0000001f615bf90] [c0000000000087fc] .start_secondary_prolog+0x10/0x14
>
> Andreas.
>
^ permalink raw reply
* Re: Windfarm's max6690 sensor driver was not included in makefile
From: Benjamin Herrenschmidt @ 2013-11-23 21:18 UTC (permalink / raw)
To: Stanislav Ponomarev; +Cc: linuxppc-dev
In-Reply-To: <CA+2fWjZRw7zdCACXXSTPN4QVeuXN5CLOZSOJJiGuP4UBcS2aMA@mail.gmail.com>
On Fri, 2013-11-22 at 15:09 -0600, Stanislav Ponomarev wrote:
> Hello, I had problems with fan speed in my XServe G5. It turned out
> drivers/macintosh/Makefile has a max6690 module missing from
> compilation list. I was advised to mail the patch to you guys.
>
>
> I'm not sure what's the proper format of the patch to be submitten
> (this is my first time). So I'm including it into the message body,
> and as an attached file.
So make sure you send it as plain text in a form that preserves tabs and
space (I don't now if gmail allows that). Also please include a
"Signed-off-by:" line.
Cheers,
Ben.
> diff --git a/drivers/macintosh/Makefile b/drivers/macintosh/Makefile
> index 6753b65..d2f0120 100644
> --- a/drivers/macintosh/Makefile
> +++ b/drivers/macintosh/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_WINDFARM_RM31) +=
> windfarm_fcu_controls.o \
> windfarm_ad7417_sensor.o \
> windfarm_lm75_sensor.o \
> windfarm_lm87_sensor.o \
> + windfarm_max6690_sensor.o \
> windfarm_pid.o \
> windfarm_cpufreq_clamp.o \
> windfarm_rm31.o
>
>
>
> Thank you.
>
> Stanislav Ponomarev.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Build regressions/improvements in v3.13-rc1
From: Geert Uytterhoeven @ 2013-11-24 9:17 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: sparclinux, linux-xtensa@linux-xtensa.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1385233105-20026-1-git-send-email-geert@linux-m68k.org>
On Sat, Nov 23, 2013 at 7:58 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> 8 regressions:
> + /scratch/kisskb/src/arch/sparc/kernel/kgdb_64.c: error: implicit declaration of function 'exception_enter' [-Werror=implicit-function-declaration]: => 162:7
> + /scratch/kisskb/src/arch/sparc/kernel/kgdb_64.c: error: implicit declaration of function 'exception_exit' [-Werror=implicit-function-declaration]: => 176:2
sparc64-allmodconfig
> + /scratch/kisskb/src/kernel/bounds.c: error: -mcall-aixdesc must be big endian: => 1:0
> + /scratch/kisskb/src/scripts/mod/devicetable-offsets.c: error: -mcall-aixdesc must be big endian: => 1:0
> + /scratch/kisskb/src/scripts/mod/empty.c: error: -mcall-aixdesc must be big endian: => 1:0
> + <stdin>: error: -mcall-aixdesc must be big endian: => 1:0
powerpc-allmodconfig
powerpc-allyesconfig
> + error: drivers/built-in.o: undefined reference to `i2c_register_driver': => .init.literal+0xd88)
> + error: sram.c: undefined reference to `devm_regmap_init_i2c': => .text+0x58ef8)
xtensa-allmodconfig
sparc-allmodconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 00/17] add COMMON_CLK support for PowerPC MPC512x
From: Gerhard Sittig @ 2013-11-24 18:39 UTC (permalink / raw)
To: linuxppc-dev, linux-arm-kernel, Anatolij Gustschin,
Mike Turquette
Cc: Mark Rutland, Detlev Zundel, Artem Bityutskiy, linux-mtd,
Jiri Slaby, linux-serial, Wolfgang Grandegger, linux-media,
devicetree, Ian Campbell, Pawel Moll, Stephen Warren, Rob Herring,
linux-can, Mark Brown, Marc Kleine-Budde, Scott Wood,
Greg Kroah-Hartman, linux-usb, linux-spi, Paul Mackerras,
David Woodhouse, Mauro Carvalho Chehab
In-Reply-To: <1384729577-7336-1-git-send-email-gsi@denx.de>
On Mon, Nov 18, 2013 at 00:06 +0100, Gerhard Sittig wrote:
>
> the series is based on v3.12, but I'll rebase against v3.13-rc1
> (when available) or any other subtree upon request
Now that v3.13-rc1 is out, I noticed that the series no longer
applies cleanly (minor context changes and conflicts) and needs
minor adjustment.
Compilation of 4/17 requires <linux/of_address.h> which no longer
is included implicitly.
PPC_CLOCK removal in 7/17 should remove <asm/clk_interface.h> as
well after all references to this header file have gone. (And
the context of the patch has changed.)
The context of 16/17 for DIU initialization has changed.
I'll wait for a few more days whether there is more feedback for
v5 (especially on the device tree backwards compat approach),
then will rebase and send out v6 of the series.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH] powerpc/signals: Improved mark VSX not saved with small contexts fix
From: Michael Neuling @ 2013-11-25 0:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Carlos O'Donell, Steve Best, linuxppc-dev, Michael Neuling,
Haren Myneni
In a recent patch:
commit c13f20ac48328b05cd3b8c19e31ed6c132b44b42
Author: Michael Neuling <mikey@neuling.org>
powerpc/signals: Mark VSX not saved with small contexts
We fixed an issue but an improved solution was later discussed after the patch
was merged.
Firstly, this patch doesn't handle the 64bit signals case, which could also hit
this issue (but has never been reported).
Secondly, the original patch isn't clear what MSR VSX should be set to. The
new approach below always clears the MSR VSX bit (to indicate no VSX is in the
context) and sets it only in the specific case where VSX is available (ie. when
VSX has been used and the signal context passed has space to provide the
state).
This reverts the original patch and replaces it with the improved solution. It
also adds a 64 bit version.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: stable@vger.kernel.org
---
arch/powerpc/kernel/signal_32.c | 16 +++++++---------
arch/powerpc/kernel/signal_64.c | 6 ++++++
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index 1844298..68027bf 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -445,6 +445,12 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
#endif /* CONFIG_ALTIVEC */
if (copy_fpr_to_user(&frame->mc_fregs, current))
return 1;
+
+ /*
+ * Clear the MSR VSX bit to indicate there is no valid state attached
+ * to this context, except in the specific case below where we set it.
+ */
+ msr &= ~MSR_VSX;
#ifdef CONFIG_VSX
/*
* Copy VSR 0-31 upper half from thread_struct to local
@@ -457,15 +463,7 @@ static int save_user_regs(struct pt_regs *regs, struct mcontext __user *frame,
if (copy_vsx_to_user(&frame->mc_vsregs, current))
return 1;
msr |= MSR_VSX;
- } else if (!ctx_has_vsx_region)
- /*
- * With a small context structure we can't hold the VSX
- * registers, hence clear the MSR value to indicate the state
- * was not saved.
- */
- msr &= ~MSR_VSX;
-
-
+ }
#endif /* CONFIG_VSX */
#ifdef CONFIG_SPE
/* save spe registers */
diff --git a/arch/powerpc/kernel/signal_64.c b/arch/powerpc/kernel/signal_64.c
index e66f67b..4299104 100644
--- a/arch/powerpc/kernel/signal_64.c
+++ b/arch/powerpc/kernel/signal_64.c
@@ -122,6 +122,12 @@ static long setup_sigcontext(struct sigcontext __user *sc, struct pt_regs *regs,
flush_fp_to_thread(current);
/* copy fpr regs and fpscr */
err |= copy_fpr_to_user(&sc->fp_regs, current);
+
+ /*
+ * Clear the MSR VSX bit to indicate there is no valid state attached
+ * to this context, except in the specific case below where we set it.
+ */
+ msr &= ~MSR_VSX;
#ifdef CONFIG_VSX
/*
* Copy VSX low doubleword to local buffer for formatting,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v7 0/4] Add dual-fifo mode support of i.MX ssi
From: Shawn Guo @ 2013-11-25 2:11 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, pawel.moll, linux-doc,
vinod.koul, s.hauer, swarren, timur, rob.herring, linux-kernel,
broonie, dmaengine, dan.j.williams, ijc+devicetree, linuxppc-dev,
linux-arm-kernel
In-Reply-To: <20131122163132.GB17344@MrMyself>
On Sat, Nov 23, 2013 at 12:31:32AM +0800, Nicolin Chen wrote:
> Hi all,
>
> I'm sorry to push this. But this series has been an orphan for a while.
> Could any one please receive and foster it?
Vinod,
I expect you will pick up the series. But otherwise, I can apply it via
IMX tree with your ACKs on the first two patches.
Shawn
^ permalink raw reply
* RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Bharat Bhushan @ 2013-11-25 5:33 UTC (permalink / raw)
To: Alex Williamson, Scott Wood
Cc: linux-pci@vger.kernel.org, agraf@suse.de, Stuart Yoder,
iommu@lists.linux-foundation.org, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1385067648.2879.421.camel@ul30vt.home>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleCBXaWxsaWFtc29u
IFttYWlsdG86YWxleC53aWxsaWFtc29uQHJlZGhhdC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgTm92
ZW1iZXIgMjIsIDIwMTMgMjozMSBBTQ0KPiBUbzogV29vZCBTY290dC1CMDc0MjENCj4gQ2M6IEJo
dXNoYW4gQmhhcmF0LVI2NTc3NzsgbGludXgtcGNpQHZnZXIua2VybmVsLm9yZzsgYWdyYWZAc3Vz
ZS5kZTsgWW9kZXINCj4gU3R1YXJ0LUIwODI0ODsgaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlv
bi5vcmc7IGJoZWxnYWFzQGdvb2dsZS5jb207IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJz
Lm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSZTogW1BBVENI
IDAvOSB2Ml0gdmZpby1wY2k6IGFkZCBzdXBwb3J0IGZvciBGcmVlc2NhbGUgSU9NTVUgKFBBTVUp
DQo+IA0KPiBPbiBUaHUsIDIwMTMtMTEtMjEgYXQgMTQ6NDcgLTA2MDAsIFNjb3R0IFdvb2Qgd3Jv
dGU6DQo+ID4gT24gVGh1LCAyMDEzLTExLTIxIGF0IDEzOjQzIC0wNzAwLCBBbGV4IFdpbGxpYW1z
b24gd3JvdGU6DQo+ID4gPiBPbiBUaHUsIDIwMTMtMTEtMjEgYXQgMTE6MjAgKzAwMDAsIEJoYXJh
dCBCaHVzaGFuIHdyb3RlOg0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogQWxleCBXaWxsaWFtc29uIFttYWlsdG86YWxleC53aWxs
aWFtc29uQHJlZGhhdC5jb21dDQo+ID4gPiA+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIx
LCAyMDEzIDEyOjE3IEFNDQo+ID4gPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+
ID4gPiA+IENjOiBqb3JvQDhieXRlcy5vcmc7IGJoZWxnYWFzQGdvb2dsZS5jb207IGFncmFmQHN1
c2UuZGU7IFdvb2QNCj4gPiA+ID4gPiBTY290dC1CMDc0MjE7IFlvZGVyIFN0dWFydC1CMDgyNDg7
DQo+ID4gPiA+ID4gaW9tbXVAbGlzdHMubGludXgtZm91bmRhdGlvbi5vcmc7IGxpbnV4LSBwY2lA
dmdlci5rZXJuZWwub3JnOw0KPiA+ID4gPiA+IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3Jn
OyBsaW51eC0ga2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gPiA+ID4gPiBCaHVzaGFuIEJoYXJh
dC1SNjU3NzcNCj4gPiA+ID4gPiBTdWJqZWN0OiBSZTogW1BBVENIIDAvOSB2Ml0gdmZpby1wY2k6
IGFkZCBzdXBwb3J0IGZvciBGcmVlc2NhbGUNCj4gPiA+ID4gPiBJT01NVSAoUEFNVSkNCj4gPiA+
ID4gPg0KPiA+ID4gPiA+IElzIFZGSU9fSU9NTVVfUEFNVV9HRVRfTVNJX0JBTktfQ09VTlQgcGVy
IGFwZXJ0dXJlIChpZS4gZWFjaA0KPiA+ID4gPiA+IHZmaW8gdXNlciBoYXMgJENPVU5UIHJlZ2lv
bnMgYXQgdGhlaXIgZGlzcG9zYWwgZXhjbHVzaXZlbHkpPw0KPiA+ID4gPg0KPiA+ID4gPiBOdW1i
ZXIgb2YgbXNpLWJhbmsgY291bnQgaXMgc3lzdGVtIHdpZGUgYW5kIG5vdCBwZXIgYXBlcnR1cmUs
IEJ1dCB3aWxsIGJlDQo+IHNldHRpbmcgd2luZG93cyBmb3IgYmFua3MgaW4gdGhlIGRldmljZSBh
cGVydHVyZS4NCj4gPiA+ID4gU28gc2F5IGlmIHdlIGFyZSBkaXJlY3QgYXNzaWduaW5nIDIgcGNp
IGRldmljZSAoYm90aCBoYXZlIGRpZmZlcmVudCBpb21tdQ0KPiBncm91cCwgc28gMiBhcGVydHVy
ZSBpbiBpb21tdSkgdG8gVk0uDQo+ID4gPiA+IE5vdyBxZW11IGNhbiBtYWtlIG9ubHkgb25lIGNh
bGwgdG8ga25vdyBob3cgbWFueSBtc2ktYmFua3MgYXJlIHRoZXJlIGJ1dA0KPiBpdCBtdXN0IHNl
dCBzdWItd2luZG93cyBmb3IgYWxsIGJhbmtzIGZvciBib3RoIHBjaSBkZXZpY2UgaW4gaXRzIHJl
c3BlY3RpdmUNCj4gYXBlcnR1cmUuDQo+ID4gPg0KPiA+ID4gSSdtIHN0aWxsIGNvbmZ1c2VkLiAg
V2hhdCBJIHdhbnQgdG8gbWFrZSBzdXJlIG9mIGlzIHRoYXQgdGhlIGJhbmtzDQo+ID4gPiBhcmUg
aW5kZXBlbmRlbnQgcGVyIGFwZXJ0dXJlLiAgRm9yIGluc3RhbmNlLCBpZiB3ZSBoYXZlIHR3byBz
ZXBhcmF0ZQ0KPiA+ID4gdXNlcnNwYWNlIHByb2Nlc3NlcyBvcGVyYXRpbmcgaW5kZXBlbmRlbnRs
eSBhbmQgdGhleSBib3RoIGNob3NlIHRvDQo+ID4gPiB1c2UgbXNpIGJhbmsgemVybyBmb3IgdGhl
aXIgZGV2aWNlLCB0aGF0J3MgYmFuayB6ZXJvIHdpdGhpbiBlYWNoDQo+ID4gPiBhcGVydHVyZSBh
bmQgZG9lc24ndCBpbnRlcmZlcmUuICBPciBhbm90aGVyIHdheSB0byBhc2sgaXMgY2FuIGENCj4g
PiA+IG1hbGljaW91cyB1c2VyIGludGVyZmVyZSB3aXRoIG90aGVyIHVzZXJzIGJ5IHVzaW5nIHRo
ZSB3cm9uZyBiYW5rLg0KPiA+ID4gVGhhbmtzLA0KPiA+DQo+ID4gVGhleSBjYW4gaW50ZXJmZXJl
Lg0KDQpXYW50IHRvIGJlIHN1cmUgb2YgaG93IHRoZXkgY2FuIGludGVyZmVyZT8NCg0KPj4gIFdp
dGggdGhpcyBoYXJkd2FyZSwgdGhlIG9ubHkgd2F5IHRvIHByZXZlbnQgdGhhdA0KPiA+IGlzIHRv
IG1ha2Ugc3VyZSB0aGF0IGEgYmFuayBpcyBub3Qgc2hhcmVkIGJ5IG11bHRpcGxlIHByb3RlY3Rp
b24gY29udGV4dHMuDQo+ID4gRm9yIHNvbWUgb2Ygb3VyIHVzZXJzLCB0aG91Z2gsIEkgYmVsaWV2
ZSBwcmV2ZW50aW5nIHRoaXMgaXMgbGVzcw0KPiA+IGltcG9ydGFudCB0aGFuIHRoZSBwZXJmb3Jt
YW5jZSBiZW5lZml0Lg0KDQpTbyBzaG91bGQgd2UgbGV0IHRoaXMgcGF0Y2ggc2VyaWVzIGluIHdp
dGhvdXQgcHJvdGVjdGlvbj8NCg0KPiANCj4gSSB0aGluayB3ZSBuZWVkIHNvbWUgc29ydCBvZiBv
d25lcnNoaXAgbW9kZWwgYXJvdW5kIHRoZSBtc2kgYmFua3MgdGhlbi4NCj4gT3RoZXJ3aXNlIHRo
ZXJlJ3Mgbm90aGluZyBwcmV2ZW50aW5nIGFub3RoZXIgdXNlcnNwYWNlIGZyb20gYXR0ZW1wdGlu
ZyBhbiBNU0kNCj4gYmFzZWQgYXR0YWNrIG9uIG90aGVyIHVzZXJzLCBvciBwZXJoYXBzIGV2ZW4g
b24gdGhlIGhvc3QuICBWRklPIGNhbid0IGFsbG93DQo+IHRoYXQuICBUaGFua3MsDQoNCldlIGhh
dmUgdmVyeSBmZXcgKDMgTVNJIGJhbmsgb24gbW9zdCBvZiBjaGlwcyksIHNvIHdlIGNhbiBub3Qg
YXNzaWduIG9uZSB0byBlYWNoIHVzZXJzcGFjZS4gV2hhdCB3ZSBjYW4gZG8gaXMgaG9zdCBhbmQg
dXNlcnNwYWNlIGRvZXMgbm90IHNoYXJlIGEgTVNJIGJhbmsgd2hpbGUgdXNlcnNwYWNlIHdpbGwg
c2hhcmUgYSBNU0kgYmFuay4NCg0KDQpUaGFua3MNCi1CaGFyYXQNCg0KPiANCj4gQWxleA0KPiAN
Cg0K
^ permalink raw reply
* [PATCH] phy: Add Vitesse 8514 phy ID
From: shh.xie @ 2013-11-25 4:40 UTC (permalink / raw)
To: linux-kernel, davem; +Cc: netdev, linuxppc-dev, Shaohui Xie
From: Shaohui Xie <Shaohui.Xie@freescale.com>
Phy is compatible with Vitesse 82xx
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
drivers/net/phy/vitesse.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
index 508e435..14372c6 100644
--- a/drivers/net/phy/vitesse.c
+++ b/drivers/net/phy/vitesse.c
@@ -64,6 +64,7 @@
#define PHY_ID_VSC8234 0x000fc620
#define PHY_ID_VSC8244 0x000fc6c0
+#define PHY_ID_VSC8514 0x00070670
#define PHY_ID_VSC8574 0x000704a0
#define PHY_ID_VSC8662 0x00070660
#define PHY_ID_VSC8221 0x000fc550
@@ -131,6 +132,7 @@ static int vsc82xx_config_intr(struct phy_device *phydev)
err = phy_write(phydev, MII_VSC8244_IMASK,
(phydev->drv->phy_id == PHY_ID_VSC8234 ||
phydev->drv->phy_id == PHY_ID_VSC8244 ||
+ phydev->drv->phy_id == PHY_ID_VSC8514 ||
phydev->drv->phy_id == PHY_ID_VSC8574) ?
MII_VSC8244_IMASK_MASK :
MII_VSC8221_IMASK_MASK);
@@ -246,6 +248,18 @@ static struct phy_driver vsc82xx_driver[] = {
.config_intr = &vsc82xx_config_intr,
.driver = { .owner = THIS_MODULE,},
}, {
+ .phy_id = PHY_ID_VSC8514,
+ .name = "Vitesse VSC8514",
+ .phy_id_mask = 0x000ffff0,
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_INTERRUPT,
+ .config_init = &vsc824x_config_init,
+ .config_aneg = &vsc82x4_config_aneg,
+ .read_status = &genphy_read_status,
+ .ack_interrupt = &vsc824x_ack_interrupt,
+ .config_intr = &vsc82xx_config_intr,
+ .driver = { .owner = THIS_MODULE,},
+}, {
.phy_id = PHY_ID_VSC8574,
.name = "Vitesse VSC8574",
.phy_id_mask = 0x000ffff0,
@@ -315,6 +329,7 @@ module_exit(vsc82xx_exit);
static struct mdio_device_id __maybe_unused vitesse_tbl[] = {
{ PHY_ID_VSC8234, 0x000ffff0 },
{ PHY_ID_VSC8244, 0x000fffc0 },
+ { PHY_ID_VSC8514, 0x000ffff0 },
{ PHY_ID_VSC8574, 0x000ffff0 },
{ PHY_ID_VSC8662, 0x000ffff0 },
{ PHY_ID_VSC8221, 0x000ffff0 },
--
1.8.4.1
^ permalink raw reply related
* [PATCH v2] PPC64: Adding symbols in vmcoreinfo to facilitate dump filtering
From: Hari Bathini @ 2013-11-25 6:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev; +Cc: Mahesh J Salgaonkar
When CONFIG_SPARSEMEM_VMEMMAP option is set in kernel, makedumpfile
tool fails to filter vmcore dump as it fails to do translations for
vmemmap addresses that are mapped outside zone normal. For vmemmap
adress translation support in this scenario, few kernel symbols are
needed by dump filtering tool. This patch adds those symbols to
vmcoreinfo, which a dump filtering tool can use for filtering the
kernel dump. This changes are tested successfully with makedumpfile
tool that supports vmemmap to physical address translation outside
zone normal.
Changes from v1:
Updated patch decription and removed #ifdef around extern.
Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/pgalloc-64.h | 2 ++
arch/powerpc/kernel/machine_kexec.c | 12 ++++++++++++
2 files changed, 14 insertions(+)
diff --git a/arch/powerpc/include/asm/pgalloc-64.h b/arch/powerpc/include/asm/pgalloc-64.h
index f65e27b..3973e62 100644
--- a/arch/powerpc/include/asm/pgalloc-64.h
+++ b/arch/powerpc/include/asm/pgalloc-64.h
@@ -17,6 +17,8 @@ struct vmemmap_backing {
unsigned long virt_addr;
};
+extern struct vmemmap_backing *vmemmap_list;
+
/*
* Functions that deal with pagetables that could be at any level of
* the table need to be passed an "index_size" so they know how to
diff --git a/arch/powerpc/kernel/machine_kexec.c b/arch/powerpc/kernel/machine_kexec.c
index e1ec57e..88a7fb4 100644
--- a/arch/powerpc/kernel/machine_kexec.c
+++ b/arch/powerpc/kernel/machine_kexec.c
@@ -18,6 +18,7 @@
#include <linux/ftrace.h>
#include <asm/machdep.h>
+#include <asm/pgalloc.h>
#include <asm/prom.h>
#include <asm/sections.h>
@@ -75,6 +76,17 @@ void arch_crash_save_vmcoreinfo(void)
#ifndef CONFIG_NEED_MULTIPLE_NODES
VMCOREINFO_SYMBOL(contig_page_data);
#endif
+#if defined(CONFIG_PPC64) && defined(CONFIG_SPARSEMEM_VMEMMAP)
+ VMCOREINFO_SYMBOL(vmemmap_list);
+ VMCOREINFO_SYMBOL(mmu_vmemmap_psize);
+ VMCOREINFO_SYMBOL(mmu_psize_defs);
+ VMCOREINFO_STRUCT_SIZE(vmemmap_backing);
+ VMCOREINFO_OFFSET(vmemmap_backing, list);
+ VMCOREINFO_OFFSET(vmemmap_backing, phys);
+ VMCOREINFO_OFFSET(vmemmap_backing, virt_addr);
+ VMCOREINFO_STRUCT_SIZE(mmu_psize_def);
+ VMCOREINFO_OFFSET(mmu_psize_def, shift);
+#endif
}
/*
^ permalink raw reply related
* [PATCH v4] KVM: PPC: vfio kvm device: support spapr tce
From: Alexey Kardashevskiy @ 2013-11-25 8:49 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, Alex Williamson, kvm-ppc, linux-kernel, kvm
In addition to the external VFIO user API, a VFIO KVM device
has been introduced recently.
sPAPR TCE IOMMU is para-virtualized and the guest does map/unmap
via hypercalls which take a logical bus id (LIOBN) as a target IOMMU
identifier. LIOBNs are made up and linked to IOMMU groups by the user
space. In order to accelerate IOMMU operations in the KVM, we need
to tell KVM the information about LIOBN-to-group mapping.
For that, a new KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN parameter
is added. It accepts a pair of a VFIO group fd and LIOBN.
This also adds a new kvm_vfio_find_group_by_liobn() function which
receives kvm struct, LIOBN and a callback. As it increases the IOMMU
group use counter, the KVMr is required to pass a callback which
called when the VFIO group is about to be removed VFIO-KVM tracking so
the KVM is able to call iommu_group_put() to release the IOMMU group.
The KVM uses kvm_vfio_find_group_by_liobn() once per KVM run and caches
the result in kvm_arch. iommu_group_put() for all groups will be called
when KVM finishes (in the SPAPR TCE in KVM enablement patch).
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v4:
* fixed few bugs
* changed kvm_vfio_find_group_by_liobn() to return informative errors
v3:
* total rework
* added a release callback into kvm_vfio_find_group_by_liobn so now
the user of the API can get a notification if the group is about to
disappear
---
Documentation/virtual/kvm/devices/vfio.txt | 19 ++++-
arch/powerpc/kvm/Kconfig | 1 +
arch/powerpc/kvm/Makefile | 3 +
include/linux/kvm_host.h | 18 +++++
include/uapi/linux/kvm.h | 7 ++
virt/kvm/vfio.c | 116 ++++++++++++++++++++++++++++-
6 files changed, 161 insertions(+), 3 deletions(-)
diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt
index ef51740..7ecb3b2 100644
--- a/Documentation/virtual/kvm/devices/vfio.txt
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -16,7 +16,22 @@ Groups:
KVM_DEV_VFIO_GROUP attributes:
KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
+ kvm_device_attr.addr points to an int32_t file descriptor
+ for the VFIO group.
+
+ KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: sets a liobn for a VFIO group
+ kvm_device_attr.addr points to a struct:
+ struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __u32 fd;
+ __u32 liobn;
+ };
+ where
+ @argsz is a struct size;
+ @fd is a file descriptor for a VFIO group;
+ @liobn is a logical bus id to be associated with the group.
-For each, kvm_device_attr.addr points to an int32_t file descriptor
-for the VFIO group.
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 9a50d82..f463958 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -60,6 +60,7 @@ config KVM_BOOK3S_64
select KVM_BOOK3S_64_HANDLER
select KVM
select SPAPR_TCE_IOMMU if IOMMU_SUPPORT
+ select KVM_VFIO
---help---
Support running unmodified book3s_64 and book3s_32 guest kernels
in virtual machines on book3s_64 host processors.
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..2438d2e 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -87,6 +87,9 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
+kvm-book3s_64-objs-$(CONFIG_KVM_VFIO) += \
+ $(KVM)/vfio.o \
+
kvm-book3s_64-module-objs := \
$(KVM)/kvm_main.o \
$(KVM)/eventfd.o \
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 88ff96a..1d2ad5e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -1112,5 +1112,23 @@ static inline bool kvm_vcpu_eligible_for_directed_yield(struct kvm_vcpu *vcpu)
}
#endif /* CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT */
+
+typedef void (*kvm_vfio_release_group_callback)(struct kvm *kvm,
+ unsigned long liobn);
+
+#if defined(CONFIG_KVM_VFIO) && defined(CONFIG_SPAPR_TCE_IOMMU)
+
+extern struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, kvm_vfio_release_group_callback cb);
+
+#else
+
+static inline struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, ikvm_vfio_release_group_callback cb)
+{
+ return NULL;
+}
+#endif /* CONFIG_KVM_VFIO && CONFIG_SPAPR_TCE_IOMMU */
+
#endif
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 7c1a349..51d5464 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -847,6 +847,13 @@ struct kvm_device_attr {
#define KVM_DEV_VFIO_GROUP 1
#define KVM_DEV_VFIO_GROUP_ADD 1
#define KVM_DEV_VFIO_GROUP_DEL 2
+#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN 3
+
+struct kvm_vfio_spapr_tce_liobn {
+ __u32 argsz;
+ __s32 fd;
+ __u32 liobn;
+};
/*
* ioctls for VM fds
diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
index ca4260e..ddc945d 100644
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -22,6 +22,12 @@
struct kvm_vfio_group {
struct list_head node;
struct vfio_group *vfio_group;
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ struct {
+ unsigned long liobn;
+ kvm_vfio_release_group_callback cb;
+ } spapr_tce;
+#endif
};
struct kvm_vfio {
@@ -59,6 +65,51 @@ static void kvm_vfio_group_put_external_user(struct vfio_group *vfio_group)
symbol_put(vfio_group_put_external_user);
}
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+struct iommu_group *kvm_vfio_find_group_by_liobn(struct kvm *kvm,
+ unsigned long liobn, kvm_vfio_release_group_callback cb)
+{
+ struct kvm_vfio_group *kvg;
+ int group_id;
+ struct iommu_group *grp;
+ struct kvm_vfio *kv = NULL;
+ struct kvm_device *tmp;
+
+ if (!cb)
+ return ERR_PTR(-EINVAL);
+
+ /* Find a VFIO KVM device */
+ list_for_each_entry(tmp, &kvm->devices, vm_node) {
+ if (tmp->ops != &kvm_vfio_ops)
+ continue;
+
+ kv = tmp->private;
+ break;
+ }
+
+ if (!kv)
+ return ERR_PTR(-EIO);
+
+ /* Find a group */
+ list_for_each_entry(kvg, &kv->group_list, node) {
+ if (kvg->spapr_tce.liobn != liobn)
+ continue;
+
+ if (kvg->spapr_tce.cb)
+ return ERR_PTR(-EBUSY);
+
+ kvg->spapr_tce.cb = cb;
+ group_id = vfio_external_user_iommu_id(kvg->vfio_group);
+ grp = iommu_group_get_by_id(group_id);
+
+ return grp;
+ }
+
+ return ERR_PTR(-ENODEV);
+}
+EXPORT_SYMBOL_GPL(kvm_vfio_find_group_by_liobn);
+#endif
+
/*
* Groups can use the same or different IOMMU domains. If the same then
* adding a new group may change the coherency of groups we've previously
@@ -140,7 +191,9 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
list_add_tail(&kvg->node, &kv->group_list);
kvg->vfio_group = vfio_group;
-
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ kvg->spapr_tce.liobn = -1;
+#endif
mutex_unlock(&kv->lock);
kvm_vfio_update_coherency(dev);
@@ -170,6 +223,11 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
continue;
list_del(&kvg->node);
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ if (kvg->spapr_tce.cb)
+ kvg->spapr_tce.cb(dev->kvm,
+ kvg->spapr_tce.liobn);
+#endif
kvm_vfio_group_put_external_user(kvg->vfio_group);
kfree(kvg);
ret = 0;
@@ -183,6 +241,59 @@ static int kvm_vfio_set_group(struct kvm_device *dev, long attr, u64 arg)
kvm_vfio_update_coherency(dev);
return ret;
+
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN: {
+ struct kvm_vfio_spapr_tce_liobn param;
+ unsigned long minsz;
+ struct kvm_vfio *kv = dev->private;
+ struct vfio_group *vfio_group;
+ struct kvm_vfio_group *kvg;
+ struct fd f;
+
+ minsz = offsetofend(struct kvm_vfio_spapr_tce_liobn, liobn);
+
+ if (copy_from_user(¶m, (void __user *)arg, minsz))
+ return -EFAULT;
+
+ if (param.argsz < minsz)
+ return -EINVAL;
+
+ f = fdget(param.fd);
+ if (!f.file)
+ return -EBADF;
+
+ vfio_group = kvm_vfio_group_get_external_user(f.file);
+ fdput(f);
+
+ if (IS_ERR(vfio_group))
+ return PTR_ERR(vfio_group);
+
+ ret = -ENOENT;
+
+ mutex_lock(&kv->lock);
+
+ list_for_each_entry(kvg, &kv->group_list, node) {
+ if (kvg->vfio_group != vfio_group)
+ continue;
+
+ if (kvg->spapr_tce.liobn != -1) {
+ ret = -EBUSY;
+ break;
+ }
+
+ kvg->spapr_tce.liobn = param.liobn;
+ ret = 0;
+ break;
+ }
+
+ mutex_unlock(&kv->lock);
+
+ kvm_vfio_group_put_external_user(vfio_group);
+
+ return ret;
+ }
+#endif /* CONFIG_SPAPR_TCE_IOMMU */
}
return -ENXIO;
@@ -207,6 +318,9 @@ static int kvm_vfio_has_attr(struct kvm_device *dev,
switch (attr->attr) {
case KVM_DEV_VFIO_GROUP_ADD:
case KVM_DEV_VFIO_GROUP_DEL:
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE_LIOBN:
+#endif
return 0;
}
--
1.8.4.rc4
^ permalink raw reply related
* [PATCH 21/24] powerpc: Separate kernel/userspace inclusion of <asm-generic/int-ll64.h>
From: Geert Uytterhoeven @ 2013-11-25 8:55 UTC (permalink / raw)
To: Arnd Bergmann, linux-arch
Cc: linuxppc-dev, Geert Uytterhoeven, linux-kernel, Paul Mackerras
In-Reply-To: <1385369734-24893-1-git-send-email-geert@linux-m68k.org>
This allows to rename the kernelspace version later.
Now arch/powerpc/include/asm/types.h includes the kernelspace version,
while arch/powerpc/include/uapi/asm/types.h includes the userspace version.
As arch/powerpc/include/uapi/asm/types.h is also included for kernelspace,
its inclusion of <asm-generic/int-ll64.h> needs to be protected by #ifndef
__KERNEL__.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/types.h | 1 +
arch/powerpc/include/uapi/asm/types.h | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index bfb6ded38ffa..4b9c3530bb12 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -13,6 +13,7 @@
#ifndef _ASM_POWERPC_TYPES_H
#define _ASM_POWERPC_TYPES_H
+#include <asm-generic/int-ll64.h>
#include <uapi/asm/types.h>
#ifndef __ASSEMBLY__
diff --git a/arch/powerpc/include/uapi/asm/types.h b/arch/powerpc/include/uapi/asm/types.h
index 4b8ab990a3c1..7f8847b61d03 100644
--- a/arch/powerpc/include/uapi/asm/types.h
+++ b/arch/powerpc/include/uapi/asm/types.h
@@ -21,11 +21,13 @@
* However, some user programs are fine with this. They can
* flag __SANE_USERSPACE_TYPES__ to get int-ll64.h here.
*/
-#if !defined(__SANE_USERSPACE_TYPES__) && defined(__powerpc64__) && !defined(__KERNEL__)
+#ifndef __KERNEL__
+#if !defined(__SANE_USERSPACE_TYPES__) && defined(__powerpc64__)
# include <asm-generic/int-l64.h>
#else
# include <asm-generic/int-ll64.h>
#endif
+#endif
#ifndef __ASSEMBLY__
--
1.7.9.5
^ permalink raw reply related
* [PATCH 24/24] asm-generic: Rename int-ll64.h to types.h
From: Geert Uytterhoeven @ 2013-11-25 8:55 UTC (permalink / raw)
To: Arnd Bergmann, linux-arch
Cc: linux-mips, linux-ia64, linux-s390, linux-xtensa, linux-sh,
linux-kernel, linux-kbuild, Geert Uytterhoeven, linux-alpha,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1385369734-24893-1-git-send-email-geert@linux-m68k.org>
Since kernelspace always uses "(unsigned) long long" for 64-bit integer
values ("u64" and "s64"), rename include/asm-generic/int-ll64.h to
include/asm-generic/types.h, as suggested by Arnd Bergmann.
Userspace still has both include/uapi/asm-generic/int-l64.h and
include/uapi/asm-generic/int-ll64.h, as int-l64.h may still be used for
userspace on existing 64-bit platforms (alpha, ia64, mips, and powerpc).
Note: While arch/alpha/include/asm/types.h just includes
asm-generic/types.h, don't be tempted to use Kbuild logic to provide it!
arch/*/include/asm/Kbuild applies to both arch/*/include/asm and
arch/*/include/uapi/asm, while alpha has its own <uapi/asm/types.h>.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-alpha@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: linux-xtensa@linux-xtensa.org
Cc: linux-kbuild@vger.kernel.org
---
Question: Is the arch/*/include/asm/Kbuild behavior intentional?
arch/alpha/include/asm/types.h | 2 +-
arch/arm/include/asm/types.h | 2 +-
arch/ia64/include/asm/types.h | 2 +-
arch/mips/include/asm/types.h | 2 +-
arch/powerpc/include/asm/types.h | 2 +-
arch/s390/include/asm/types.h | 2 +-
arch/sh/include/asm/types.h | 2 +-
arch/xtensa/include/asm/types.h | 2 +-
include/asm-generic/io-64-nonatomic-hi-lo.h | 2 +-
include/asm-generic/io-64-nonatomic-lo-hi.h | 2 +-
include/asm-generic/{int-ll64.h => types.h} | 8 ++++----
11 files changed, 14 insertions(+), 14 deletions(-)
rename include/asm-generic/{int-ll64.h => types.h} (85%)
diff --git a/arch/alpha/include/asm/types.h b/arch/alpha/include/asm/types.h
index 4cb4b6d3452c..b86fb65c5b10 100644
--- a/arch/alpha/include/asm/types.h
+++ b/arch/alpha/include/asm/types.h
@@ -1,6 +1,6 @@
#ifndef _ALPHA_TYPES_H
#define _ALPHA_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#endif /* _ALPHA_TYPES_H */
diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index a53cdb8f068c..09e15a8a40b1 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -1,7 +1,7 @@
#ifndef _ASM_TYPES_H
#define _ASM_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
/*
* The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
diff --git a/arch/ia64/include/asm/types.h b/arch/ia64/include/asm/types.h
index 4c351b169da2..6bc2e8acadd7 100644
--- a/arch/ia64/include/asm/types.h
+++ b/arch/ia64/include/asm/types.h
@@ -13,7 +13,7 @@
#ifndef _ASM_IA64_TYPES_H
#define _ASM_IA64_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#include <uapi/asm/types.h>
#ifdef __ASSEMBLY__
diff --git a/arch/mips/include/asm/types.h b/arch/mips/include/asm/types.h
index 4d5ce4c9c924..0d6729329a6a 100644
--- a/arch/mips/include/asm/types.h
+++ b/arch/mips/include/asm/types.h
@@ -11,7 +11,7 @@
#ifndef _ASM_TYPES_H
#define _ASM_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
/*
* These aren't exported outside the kernel to avoid name space clashes
diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
index 4b9c3530bb12..69d42a918e0e 100644
--- a/arch/powerpc/include/asm/types.h
+++ b/arch/powerpc/include/asm/types.h
@@ -13,7 +13,7 @@
#ifndef _ASM_POWERPC_TYPES_H
#define _ASM_POWERPC_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#include <uapi/asm/types.h>
#ifndef __ASSEMBLY__
diff --git a/arch/s390/include/asm/types.h b/arch/s390/include/asm/types.h
index a5c7e829dbc3..abb93c7f0125 100644
--- a/arch/s390/include/asm/types.h
+++ b/arch/s390/include/asm/types.h
@@ -6,7 +6,7 @@
#ifndef _S390_TYPES_H
#define _S390_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#include <uapi/asm/types.h>
/*
diff --git a/arch/sh/include/asm/types.h b/arch/sh/include/asm/types.h
index 062324be5cd6..ef745dcfd926 100644
--- a/arch/sh/include/asm/types.h
+++ b/arch/sh/include/asm/types.h
@@ -1,7 +1,7 @@
#ifndef __ASM_SH_TYPES_H
#define __ASM_SH_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
/*
* These aren't exported outside the kernel to avoid name space clashes
diff --git a/arch/xtensa/include/asm/types.h b/arch/xtensa/include/asm/types.h
index d873cb17d944..20ffdf440e4f 100644
--- a/arch/xtensa/include/asm/types.h
+++ b/arch/xtensa/include/asm/types.h
@@ -10,7 +10,7 @@
#ifndef _XTENSA_TYPES_H
#define _XTENSA_TYPES_H
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#include <uapi/asm/types.h>
#endif /* _XTENSA_TYPES_H */
diff --git a/include/asm-generic/io-64-nonatomic-hi-lo.h b/include/asm-generic/io-64-nonatomic-hi-lo.h
index a6806a94250d..414d2c49d53c 100644
--- a/include/asm-generic/io-64-nonatomic-hi-lo.h
+++ b/include/asm-generic/io-64-nonatomic-hi-lo.h
@@ -2,7 +2,7 @@
#define _ASM_IO_64_NONATOMIC_HI_LO_H_
#include <linux/io.h>
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#ifndef readq
static inline __u64 readq(const volatile void __iomem *addr)
diff --git a/include/asm-generic/io-64-nonatomic-lo-hi.h b/include/asm-generic/io-64-nonatomic-lo-hi.h
index ca546b1ff8b5..9bc5a3393ca1 100644
--- a/include/asm-generic/io-64-nonatomic-lo-hi.h
+++ b/include/asm-generic/io-64-nonatomic-lo-hi.h
@@ -2,7 +2,7 @@
#define _ASM_IO_64_NONATOMIC_LO_HI_H_
#include <linux/io.h>
-#include <asm-generic/int-ll64.h>
+#include <asm-generic/types.h>
#ifndef readq
static inline __u64 readq(const volatile void __iomem *addr)
diff --git a/include/asm-generic/int-ll64.h b/include/asm-generic/types.h
similarity index 85%
rename from include/asm-generic/int-ll64.h
rename to include/asm-generic/types.h
index 4cd84855cb46..b9542bb3d991 100644
--- a/include/asm-generic/int-ll64.h
+++ b/include/asm-generic/types.h
@@ -1,11 +1,11 @@
/*
- * asm-generic/int-ll64.h
+ * asm-generic/types.h
*
* Integer declarations for architectures which use "long long"
* for 64-bit types.
*/
-#ifndef _ASM_GENERIC_INT_LL64_H
-#define _ASM_GENERIC_INT_LL64_H
+#ifndef _ASM_GENERIC_TYPES_H
+#define _ASM_GENERIC_TYPES_H
#include <uapi/asm-generic/int-ll64.h>
@@ -46,4 +46,4 @@ typedef unsigned long long u64;
#endif /* __ASSEMBLY__ */
-#endif /* _ASM_GENERIC_INT_LL64_H */
+#endif /* _ASM_GENERIC_TYPES_H */
--
1.7.9.5
^ permalink raw reply related
* [PATCH] powerpc/dts/virtex440: declare address/size-cells for phy device
From: Ian Campbell @ 2013-11-25 9:42 UTC (permalink / raw)
To: linuxppc-dev
Cc: devicetree, Ian Campbell, linux-kernel, Paul Mackerras,
Gernot Vormayr
This fixes a warning:
DTC arch/powerpc/boot/virtex440-ml507.dtb
Warning (reg_format): "reg" property in /plb@0/xps-ll-temac@81c00000/ethernet@81c00000/phy@7 has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Warning (avoid_default_addr_size): Relying on default #address-cells value for /plb@0/xps-ll-temac@81c00000/ethernet@81c00000/phy@7
Warning (avoid_default_addr_size): Relying on default #size-cells value for /plb@0/xps-ll-temac@81c00000/ethernet@81c00000/phy@7
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Gernot Vormayr <gvormayr@gmail.com>
Cc: devicetree@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
No reply since June. http://patchwork.ozlabs.org/patch/248235/
---
arch/powerpc/boot/dts/virtex440-ml507.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/dts/virtex440-ml507.dts b/arch/powerpc/boot/dts/virtex440-ml507.dts
index fc7073b..391a4e2 100644
--- a/arch/powerpc/boot/dts/virtex440-ml507.dts
+++ b/arch/powerpc/boot/dts/virtex440-ml507.dts
@@ -257,6 +257,8 @@
#size-cells = <1>;
compatible = "xlnx,compound";
ethernet@81c00000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible = "xlnx,xps-ll-temac-1.01.b";
device_type = "network";
interrupt-parent = <&xps_intc_0>;
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox