* Re: [PATCH v5 08/17] spi: mpc512x: adjust to OF based clock lookup
From: Gerhard Sittig @ 2013-11-25 19:06 UTC (permalink / raw)
To: Mark Brown
Cc: Mike Turquette, Detlev Zundel, linux-spi, Scott Wood,
Anatolij Gustschin, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20131125173008.GQ14725@sirena.org.uk>
On Mon, Nov 25, 2013 at 17:30 +0000, Mark Brown wrote:
>
> On Mon, Nov 18, 2013 at 12:06:08AM +0100, Gerhard Sittig wrote:
> > after device tree based clock lookup became available, the peripheral
> > driver need no longer construct clock names which include the PSC index,
> > remove the "psc%d_mclk" template and unconditionally use 'mclk'
>
> Have there been other changes which make this happen?
Not yet in mainline. The patch you respond to is 08/17 within
the series, and depends on earlier patches in the series (namely
the introduction of CCF support for the MPC512x platform, making
the 'mclk' lookup against the PSC's OF node work while keeping
the global 'pscN_mclk' in place during migration).
This information was listed in the cover letter, but was not
duplicated within the individual patches. Patches were sent to
individual Cc: lists to not spam too many people, but the cover
letter was CC'ed to every recipient of any part of the series.
Please note that I will have to re-submit the series, since it no
longer cleanly applies against v3.13-rc1 (which was not available
when I sent v5). This patch won't change in its content, but may
experience changes in its context (catchup with changes between
v3.12 and v3.13-rc1).
Thank you for considering the patch, and for your feedback on
past versions!
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
* Re: [PATCH v5 08/17] spi: mpc512x: adjust to OF based clock lookup
From: Mark Brown @ 2013-11-25 17:30 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Mike Turquette, Detlev Zundel, linux-spi, Scott Wood,
Anatolij Gustschin, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384729577-7336-9-git-send-email-gsi@denx.de>
[-- Attachment #1: Type: text/plain, Size: 332 bytes --]
On Mon, Nov 18, 2013 at 12:06:08AM +0100, Gerhard Sittig wrote:
> after device tree based clock lookup became available, the peripheral
> driver need no longer construct clock names which include the PSC index,
> remove the "psc%d_mclk" template and unconditionally use 'mclk'
Have there been other changes which make this happen?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
From: Alex Williamson @ 2013-11-25 16:38 UTC (permalink / raw)
To: Bharat Bhushan
Cc: linux-pci@vger.kernel.org, agraf@suse.de, Stuart Yoder,
bhelgaas@google.com, iommu@lists.linux-foundation.org, Scott Wood,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0722C180@039-SN2MPN1-012.039d.mgd.msft.net>
On Mon, 2013-11-25 at 05:33 +0000, Bharat Bhushan wrote:
>
> > -----Original Message-----
> > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > Sent: Friday, November 22, 2013 2:31 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linux-pci@vger.kernel.org; agraf@suse.de; Yoder
> > Stuart-B08248; iommu@lists.linux-foundation.org; bhelgaas@google.com; linuxppc-
> > dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> >
> > On Thu, 2013-11-21 at 14:47 -0600, Scott Wood wrote:
> > > On Thu, 2013-11-21 at 13:43 -0700, Alex Williamson wrote:
> > > > On Thu, 2013-11-21 at 11:20 +0000, Bharat Bhushan wrote:
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Alex Williamson [mailto:alex.williamson@redhat.com]
> > > > > > Sent: Thursday, November 21, 2013 12:17 AM
> > > > > > To: Bhushan Bharat-R65777
> > > > > > Cc: joro@8bytes.org; bhelgaas@google.com; agraf@suse.de; Wood
> > > > > > Scott-B07421; Yoder Stuart-B08248;
> > > > > > iommu@lists.linux-foundation.org; linux- pci@vger.kernel.org;
> > > > > > linuxppc-dev@lists.ozlabs.org; linux- kernel@vger.kernel.org;
> > > > > > Bhushan Bharat-R65777
> > > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > > IOMMU (PAMU)
> > > > > >
> > > > > > Is VFIO_IOMMU_PAMU_GET_MSI_BANK_COUNT per aperture (ie. each
> > > > > > vfio user has $COUNT regions at their disposal exclusively)?
> > > > >
> > > > > Number of msi-bank count is system wide and not per aperture, But will be
> > setting windows for banks in the device aperture.
> > > > > So say if we are direct assigning 2 pci device (both have different iommu
> > group, so 2 aperture in iommu) to VM.
> > > > > Now qemu can make only one call to know how many msi-banks are there but
> > it must set sub-windows for all banks for both pci device in its respective
> > aperture.
> > > >
> > > > I'm still confused. What I want to make sure of is that the banks
> > > > are independent per aperture. For instance, if we have two separate
> > > > userspace processes operating independently and they both chose to
> > > > use msi bank zero for their device, that's bank zero within each
> > > > aperture and doesn't interfere. Or another way to ask is can a
> > > > malicious user interfere with other users by using the wrong bank.
> > > > Thanks,
> > >
> > > They can interfere.
>
> Want to be sure of how they can interfere?
What happens if more than one user selects the same MSI bank?
Minimally, wouldn't that result in the IOMMU blocking transactions from
the previous user once the new user activates their mapping?
> >> With this hardware, the only way to prevent that
> > > is to make sure that a bank is not shared by multiple protection contexts.
> > > For some of our users, though, I believe preventing this is less
> > > important than the performance benefit.
>
> So should we let this patch series in without protection?
No.
> >
> > I think we need some sort of ownership model around the msi banks then.
> > Otherwise there's nothing preventing another userspace from attempting an MSI
> > based attack on other users, or perhaps even on the host. VFIO can't allow
> > that. Thanks,
>
> We have very few (3 MSI bank on most of chips), so we can not assign
> one to each userspace. What we can do is host and userspace does not
> share a MSI bank while userspace will share a MSI bank.
Then you probably need VFIO to "own" the MSI bank and program devices
into it rather than exposing the MSI banks to userspace to let them have
direct access. Thanks,
Alex
^ permalink raw reply
* [PATCH v2 01/11] Add generic fixmap.h
From: Mark Salter @ 2013-11-25 16:13 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
linux-hexagon, microblaze-uclinux, Richard Kuo, Mark Salter,
Paul Mackerras, linuxppc-dev, linux-metag, linux-arm-kernel
In-Reply-To: <1385396045-15852-1-git-send-email-msalter@redhat.com>
Many architectures provide an asm/fixmap.h which defines support for
compile-time 'special' virtual mappings which need to be made before
paging_init() has run. This support is also used for early ioremap
on x86. Much of this support is identical across the architectures.
This patch consolidates all of the common bits into asm-generic/fixmap.h
which is intended to be included from arch/*/include/asm/fixmap.h.
Signed-off-by: Mark Salter <msalter@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
CC: linux-arch@vger.kernel.org
CC: Russell King <linux@arm.linux.org.uk>
CC: linux-arm-kernel@lists.infradead.org
CC: Richard Kuo <rkuo@codeaurora.org>
CC: linux-hexagon@vger.kernel.org
CC: James Hogan <james.hogan@imgtec.com>
CC: linux-metag@vger.kernel.org
CC: Michal Simek <monstr@monstr.eu>
CC: microblaze-uclinux@itee.uq.edu.au
CC: linux-mips@linux-mips.org
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
---
include/asm-generic/fixmap.h | 97 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 97 insertions(+)
create mode 100644 include/asm-generic/fixmap.h
diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h
new file mode 100644
index 0000000..5a64ca4
--- /dev/null
+++ b/include/asm-generic/fixmap.h
@@ -0,0 +1,97 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ * x86_32 and x86_64 integration by Gustavo F. Padovan, February 2009
+ * Break out common bits to asm-generic by Mark Salter, November 2013
+ */
+
+#ifndef __ASM_GENERIC_FIXMAP_H
+#define __ASM_GENERIC_FIXMAP_H
+
+#include <linux/bug.h>
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+
+#ifndef __ASSEMBLY__
+/*
+ * 'index to address' translation. If anyone tries to use the idx
+ * directly without translation, we catch the bug with a NULL-deference
+ * kernel oops. Illegal ranges of incoming indices are caught too.
+ */
+static __always_inline unsigned long fix_to_virt(const unsigned int idx)
+{
+ BUILD_BUG_ON(idx >= __end_of_fixed_addresses);
+ return __fix_to_virt(idx);
+}
+
+static inline unsigned long virt_to_fix(const unsigned long vaddr)
+{
+ BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
+ return __virt_to_fix(vaddr);
+}
+
+/*
+ * Provide some reasonable defaults for page flags.
+ * Not all architectures use all of these different types and some
+ * architectures use different names.
+ */
+#ifndef FIXMAP_PAGE_NORMAL
+#define FIXMAP_PAGE_NORMAL PAGE_KERNEL
+#endif
+#ifndef FIXMAP_PAGE_NOCACHE
+#define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NOCACHE
+#endif
+#ifndef FIXMAP_PAGE_IO
+#define FIXMAP_PAGE_IO PAGE_KERNEL_IO
+#endif
+#ifndef FIXMAP_PAGE_CLEAR
+#define FIXMAP_PAGE_CLEAR __pgprot(0)
+#endif
+
+#ifndef set_fixmap
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_NORMAL)
+#endif
+
+#ifndef clear_fixmap
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, FIXMAP_PAGE_CLEAR)
+#endif
+
+/* Return a pointer with offset calculated */
+#define __set_fixmap_offset(idx, phys, flags) \
+({ \
+ unsigned long addr; \
+ __set_fixmap(idx, phys, flags); \
+ addr = fix_to_virt(idx) + ((phys) & (PAGE_SIZE - 1)); \
+ addr; \
+})
+
+#define set_fixmap_offset(idx, phys) \
+ __set_fixmap_offset(idx, phys, FIXMAP_PAGE_NORMAL)
+
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_NOCACHE)
+
+#define set_fixmap_offset_nocache(idx, phys) \
+ __set_fixmap_offset(idx, phys, FIXMAP_PAGE_NOCACHE)
+
+/*
+ * Some fixmaps are for IO
+ */
+#define set_fixmap_io(idx, phys) \
+ __set_fixmap(idx, phys, FIXMAP_PAGE_IO)
+
+#endif /* __ASSEMBLY__ */
+#endif /* __ASM_GENERIC_FIXMAP_H */
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2 00/11] Consolidate asm/fixmap.h files
From: Mark Salter @ 2013-11-25 16:13 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, linux-mips, Michal Simek, James Hogan, Russell King,
Arnd Bergmann, linux-hexagon, microblaze-uclinux, Ralf Baechle,
Richard Kuo, Mark Salter, Paul Mackerras, linuxppc-dev,
linux-metag, linux-arm-kernel
Many architectures provide an asm/fixmap.h which defines support for
compile-time 'special' virtual mappings which need to be made before
paging_init() has run. This suport is also used for early ioremap
on x86. Much of this support is identical across the architectures.
This patch consolidates all of the common bits into asm-generic/fixmap.h
which is intended to be included from arch/*/include/asm/fixmap.h.
This has been compiled on x86, arm, powerpc, and sh, but tested
on x86 only.
This is version two of the patch series:
git://github.com/mosalter/linux.git#fixmap-v2
Version 1 is here:
git://github.com/mosalter/linux.git#fixmap
Changes from v1:
* Added acks from feedback.
* Use BUILD_BUG_ON in fix_to_virt()
* Fixed ARM patch to make FIXMAP_TOP inclusive of fixmap
range as is the case in the other architectures.
Mark Salter (11):
Add generic fixmap.h
x86: use generic fixmap.h
arm: use generic fixmap.h
hexagon: use generic fixmap.h
metag: use generic fixmap.h
microblaze: use generic fixmap.h
mips: use generic fixmap.h
powerpc: use generic fixmap.h
sh: use generic fixmap.h
tile: use generic fixmap.h
um: use generic fixmap.h
arch/arm/include/asm/fixmap.h | 29 +++--------
arch/arm/mm/init.c | 2 +-
arch/hexagon/include/asm/fixmap.h | 40 +--------------
arch/metag/include/asm/fixmap.h | 32 +-----------
arch/microblaze/include/asm/fixmap.h | 44 +---------------
arch/mips/include/asm/fixmap.h | 33 +-----------
arch/powerpc/include/asm/fixmap.h | 44 +---------------
arch/sh/include/asm/fixmap.h | 39 +--------------
arch/tile/include/asm/fixmap.h | 33 +-----------
arch/um/include/asm/fixmap.h | 40 +--------------
arch/x86/include/asm/fixmap.h | 59 +---------------------
include/asm-generic/fixmap.h | 97 ++++++++++++++++++++++++++++++++++++
12 files changed, 118 insertions(+), 374 deletions(-)
create mode 100644 include/asm-generic/fixmap.h
--
1.8.3.1
^ permalink raw reply
* [PATCH v2 08/11] powerpc: use generic fixmap.h
From: Mark Salter @ 2013-11-25 16:14 UTC (permalink / raw)
To: linux-kernel; +Cc: Paul Mackerras, linuxppc-dev, Mark Salter
In-Reply-To: <1385396045-15852-1-git-send-email-msalter@redhat.com>
Signed-off-by: Mark Salter <msalter@redhat.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/include/asm/fixmap.h | 44 ++-------------------------------------
1 file changed, 2 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/include/asm/fixmap.h b/arch/powerpc/include/asm/fixmap.h
index 5c2c023..90f604b 100644
--- a/arch/powerpc/include/asm/fixmap.h
+++ b/arch/powerpc/include/asm/fixmap.h
@@ -58,52 +58,12 @@ enum fixed_addresses {
extern void __set_fixmap (enum fixed_addresses idx,
phys_addr_t phys, pgprot_t flags);
-#define set_fixmap(idx, phys) \
- __set_fixmap(idx, phys, PAGE_KERNEL)
-/*
- * Some hardware wants to get fixmapped without caching.
- */
-#define set_fixmap_nocache(idx, phys) \
- __set_fixmap(idx, phys, PAGE_KERNEL_NCG)
-
-#define clear_fixmap(idx) \
- __set_fixmap(idx, 0, __pgprot(0))
-
#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
-#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
-#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
-
-extern void __this_fixmap_does_not_exist(void);
-
-/*
- * 'index to address' translation. If anyone tries to use the idx
- * directly without tranlation, we catch the bug with a NULL-deference
- * kernel oops. Illegal ranges of incoming indices are caught too.
- */
-static __always_inline unsigned long fix_to_virt(const unsigned int idx)
-{
- /*
- * this branch gets completely eliminated after inlining,
- * except when someone tries to use fixaddr indices in an
- * illegal way. (such as mixing up address types or using
- * out-of-range indices).
- *
- * If it doesn't get removed, the linker will complain
- * loudly with a reasonably clear error message..
- */
- if (idx >= __end_of_fixed_addresses)
- __this_fixmap_does_not_exist();
-
- return __fix_to_virt(idx);
-}
+#define FIXMAP_PAGE_NOCACHE PAGE_KERNEL_NCG
-static inline unsigned long virt_to_fix(const unsigned long vaddr)
-{
- BUG_ON(vaddr >= FIXADDR_TOP || vaddr < FIXADDR_START);
- return __virt_to_fix(vaddr);
-}
+#include <asm-generic/fixmap.h>
#endif /* !__ASSEMBLY__ */
#endif
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] powerpc/4xx: Fix warning in kilauea.dtb
From: Josh Boyer @ 2013-11-25 12:47 UTC (permalink / raw)
To: Ian Campbell, Benjamin Herrenschmidt
Cc: open list:OPEN FIRMWARE AND..., Tirumala R Marri, Rupjyoti Sarmah,
Linux-Kernel@Vger. Kernel. Org, Paul Mackerras, linuxppc-dev
In-Reply-To: <1385372437-20958-1-git-send-email-ian.campbell@citrix.com>
On Mon, Nov 25, 2013 at 4:40 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> Currently I see:
> DTC arch/powerpc/boot/kilauea.dtb
> Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C10000000 has invalid length (12 bytes) (#address-cells == 1, #size-cells == 1)
>
> It appears that unlike the other platforms handled by 3fb7933850fa
> "powerpc/4xx: Adding PCIe MSI support" this platform does not use address-cells=2.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Acked-by: Josh Boyer <jwboyer@gmail.com>
> Cc: Rupjyoti Sarmah <rsarmah@apm.com>
> Cc: Tirumala R Marri <tmarri@apm.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND...)
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Resending, this hasn't been picked up since June
> http://patchwork.ozlabs.org/patch/248234/
Ben, please pick this up.
josh
> ---
> arch/powerpc/boot/dts/kilauea.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
> index 1613d6e..5ba7f01 100644
> --- a/arch/powerpc/boot/dts/kilauea.dts
> +++ b/arch/powerpc/boot/dts/kilauea.dts
> @@ -406,7 +406,7 @@
>
> MSI: ppc4xx-msi@C10000000 {
> compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
> - reg = < 0x0 0xEF620000 0x100>;
> + reg = <0xEF620000 0x100>;
> sdr-base = <0x4B0>;
> msi-data = <0x00000000>;
> msi-mask = <0x44440000>;
> --
> 1.7.10.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] powerpc/4xx: Fix warning in kilauea.dtb
From: Ian Campbell @ 2013-11-25 9:40 UTC (permalink / raw)
To: linuxppc-dev
Cc: open list:OPEN FIRMWARE AND..., Ian Campbell, Tirumala R Marri,
Rupjyoti Sarmah, linux-kernel, Paul Mackerras
Currently I see:
DTC arch/powerpc/boot/kilauea.dtb
Warning (reg_format): "reg" property in /plb/ppc4xx-msi@C10000000 has invalid length (12 bytes) (#address-cells == 1, #size-cells == 1)
It appears that unlike the other platforms handled by 3fb7933850fa
"powerpc/4xx: Adding PCIe MSI support" this platform does not use address-cells=2.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Josh Boyer <jwboyer@gmail.com>
Cc: Rupjyoti Sarmah <rsarmah@apm.com>
Cc: Tirumala R Marri <tmarri@apm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: devicetree@vger.kernel.org (open list:OPEN FIRMWARE AND...)
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
Resending, this hasn't been picked up since June
http://patchwork.ozlabs.org/patch/248234/
---
arch/powerpc/boot/dts/kilauea.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/kilauea.dts b/arch/powerpc/boot/dts/kilauea.dts
index 1613d6e..5ba7f01 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -406,7 +406,7 @@
MSI: ppc4xx-msi@C10000000 {
compatible = "amcc,ppc4xx-msi", "ppc4xx-msi";
- reg = < 0x0 0xEF620000 0x100>;
+ reg = <0xEF620000 0x100>;
sdr-base = <0x4B0>;
msi-data = <0x00000000>;
msi-mask = <0x44440000>;
--
1.7.10.4
^ 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
* [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 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 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 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] 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
* 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
* 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
* [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 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
* 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: 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: 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: [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: [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
* [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 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
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