(unknown)

(unknown)

[Mr.Jerry Smith]

We Give Out Loans At 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans Or Business Loan, Email Us At jerryfunds11@inbox.lv  With Amount Needed And Phone Number.

(unknown)

[Christoph Hellwig]

To: iommu@lists.linux-foundation.org
Cc: linux-arch@vger.kernel.org
Cc: Michal Simek <monstr@monstr.eu>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: linux-alpha@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-c6x-dev@linux-c6x.org
Cc: linux-hexagon@vger.kernel.org
Cc: linux-m68k@lists.linux-m68k.org
Cc: nios2-dev@lists.rocketboards.org
Cc: openrisc@lists.librecores.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: sparclinux@vger.kernel.org
Cc: linux-xtensa@linux-xtensa.org
Cc: linux-kernel@vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops

Hi all,

this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.

The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers.  The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations.  Hopefully we can do some consolidation for them later on
as well.

A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch.  Please review them very careful and correct me on
incorrect assumptions.

Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it.  It is provided here:

    git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent

(unknown)

[Helge Deller]

(unknown)

[m.wierczynska]

[-- Attachment #1: 449666.doc --]
[-- Type: application/msword, Size: 41783 bytes --]

(unknown)

[catherine.verge]

[-- Attachment #1: MAIL_9444780361_linux-parisc.zip --]
[-- Type: application/zip, Size: 97803 bytes --]

(unknown)

[catherine.verge]

[-- Attachment #1: 7770632.zip --]
[-- Type: application/zip, Size: 13836 bytes --]

(unknown)

[catherine.verge]

[-- Attachment #1: EMAIL_7905004_linux-parisc.zip --]
[-- Type: application/zip, Size: 1654 bytes --]

(unknown)

[askeeta]

[-- Attachment #1: EMAIL_52728_linux-parisc.zip --]
[-- Type: application/zip, Size: 2732 bytes --]

(unknown)

[askeeta]

[-- Attachment #1: 750388275461_linux-parisc.zip --]
[-- Type: application/zip, Size: 4876 bytes --]

Re: [PATCH v2 0/7] uapi: export all headers under uapi directories

[Arnd Bergmann]

On Friday, January 6, 2017 10:43:52 AM CET Nicolas Dichtel wrote:
> Here is the v2 of this series. The first 5 patches are just cleanup: some
> exported headers were still under a non-uapi directory.

Since this is meant as a cleanup, I commented on this to point out a cleaner
way to do the same.

> The patch 6 was spotted by code review: there is no in-tree user of this
> functionality.
> The last patch remove the use of header-y. Now all files under an uapi
> directory are exported.

Very nice!

> asm is a bit special, most of architectures export asm/<arch>/include/uapi/asm
> only, but there is two exceptions:
>  - cris which exports arch/cris/include/uapi/arch-v[10|32];

This is interesting, though not your problem. Maybe someone who understands
cris better can comment on this: How is the decision made about which of
the arch/user.h headers gets used? I couldn't find that in the sources,
but it appears to be based on kernel compile-time settings, which is
wrong for user space header files that should be independent of the kernel
config.

>  - tile which exports arch/tile/include/uapi/arch.
> Because I don't know if the output of 'make headers_install_all' can be changed,
> I introduce subdir-y in Kbuild file. The headers_install_all target copies all
> asm/<arch>/include/uapi/asm to usr/include/asm-<arch> but
> arch/cris/include/uapi/arch-v[10|32] and arch/tile/include/uapi/arch are not
> prefixed (they are put asis in usr/include/). If it's acceptable to modify the
> output of 'make headers_install_all' to export asm headers in
> usr/include/asm-<arch>/asm, then I could remove this new subdir-y and exports
> everything under arch/<arch>/include/uapi/.

I don't know if anyone still uses "make headers_install_all", I suspect
distros these days all use "make headers_install", so it probably
doesn't matter much.

In case of cris, it should be easy enough to move all the contents of the
uapi/arch-*/*.h headers into the respective uapi/asm/*.h headers, they
only seem to be referenced from there.

For tile, I suspect that would not work as the arch/*.h headers are
apparently defined as interfaces for both user space and kernel.

> Note also that exported files for asm are a mix of files listed by:
>  - include/uapi/asm-generic/Kbuild.asm;
>  - arch/x86/include/uapi/asm/Kbuild;
>  - arch/x86/include/asm/Kbuild.
> This complicates a lot the processing (arch/x86/include/asm/Kbuild is also
> used by scripts/Makefile.asm-generic).
> 
> This series has been tested with a 'make headers_install' on x86 and a
> 'make headers_install_all'. I've checked the result of both commands.
> 
> This patch is built against linus tree. I don't know if it should be
> made against antoher tree.

The series should probably get merged through the kbuild tree, but testing
it on mainline is fine here.

	Arnd

[PATCH v3 0/8] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Here is the v3 of this series. The first 5 patches are just cleanup: some
exported headers were still under a non-uapi directory or (x86 case) were
wrongly exported.
The patch 6 was spotted by code review: there is no in-tree user of this
functionality.
Patches 7 and 8 remove the need to list explicitly headers. Now all files
under an uapi directory are exported.

This series has been tested with a 'make headers_install' on x86 and a
'make headers_install_all'. I've checked the result of both commands.

This patch is built against linus tree. If I must rebase it against the kbuild
tree, just tell me ;-)

v2 -> v3:
 - patch #1: remove arch/arm/include/asm/types.h
 - patch #2: remove arch/h8300/include/asm/bitsperlong.h
 - patch #3: remove arch/nios2/include/uapi/asm/setup.h
 - patch #4: don't export msr-index.h
 - patch #5: fix a typo: s/unput-files3-name/input-files3-name
 - patch #6: no change
 - patch #7: fix include/uapi/asm-generic/Kbuild.asm by introducing mandatory-y
 - add patch #8

v1 -> v2:
 - add patch #1 to #6
 - patch #7: remove use of header-y

Comments are welcomed,
Nicolas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v3 1/8] arm: put types.h in uapi

[Nicolas Dichtel]

This header file is exported, thus move it to uapi.

Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
---
 arch/arm/include/asm/types.h      | 40 ---------------------------------------
 arch/arm/include/uapi/asm/types.h | 40 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 40 insertions(+), 40 deletions(-)
 delete mode 100644 arch/arm/include/asm/types.h
 create mode 100644 arch/arm/include/uapi/asm/types.h

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
deleted file mode 100644
index a53cdb8f068c..000000000000
--- a/arch/arm/include/asm/types.h
+++ /dev/null
@@ -1,40 +0,0 @@
-#ifndef _ASM_TYPES_H
-#define _ASM_TYPES_H
-
-#include <asm-generic/int-ll64.h>
-
-/*
- * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
- * unambiguous on ARM as you would expect. For the types below, there is a
- * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
- * and the kernel itself, which results in build errors if you try to build with
- * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
- * in order to use NEON intrinsics)
- *
- * As the typedefs for these types in 'stdint.h' are based on builtin defines
- * supplied by GCC, we can tweak these to align with the kernel's idea of those
- * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
- * source file (provided that -ffreestanding is used).
- *
- *                    int32_t         uint32_t               uintptr_t
- * bare metal GCC     long            unsigned long          unsigned int
- * glibc GCC          int             unsigned int           unsigned int
- * kernel             int             unsigned int           unsigned long
- */
-
-#ifdef __INT32_TYPE__
-#undef __INT32_TYPE__
-#define __INT32_TYPE__		int
-#endif
-
-#ifdef __UINT32_TYPE__
-#undef __UINT32_TYPE__
-#define __UINT32_TYPE__	unsigned int
-#endif
-
-#ifdef __UINTPTR_TYPE__
-#undef __UINTPTR_TYPE__
-#define __UINTPTR_TYPE__	unsigned long
-#endif
-
-#endif /* _ASM_TYPES_H */
diff --git a/arch/arm/include/uapi/asm/types.h b/arch/arm/include/uapi/asm/types.h
new file mode 100644
index 000000000000..9435a42f575e
--- /dev/null
+++ b/arch/arm/include/uapi/asm/types.h
@@ -0,0 +1,40 @@
+#ifndef _UAPI_ASM_TYPES_H
+#define _UAPI_ASM_TYPES_H
+
+#include <asm-generic/int-ll64.h>
+
+/*
+ * The C99 types uintXX_t that are usually defined in 'stdint.h' are not as
+ * unambiguous on ARM as you would expect. For the types below, there is a
+ * difference on ARM between GCC built for bare metal ARM, GCC built for glibc
+ * and the kernel itself, which results in build errors if you try to build with
+ * -ffreestanding and include 'stdint.h' (such as when you include 'arm_neon.h'
+ * in order to use NEON intrinsics)
+ *
+ * As the typedefs for these types in 'stdint.h' are based on builtin defines
+ * supplied by GCC, we can tweak these to align with the kernel's idea of those
+ * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
+ * source file (provided that -ffreestanding is used).
+ *
+ *                    int32_t         uint32_t               uintptr_t
+ * bare metal GCC     long            unsigned long          unsigned int
+ * glibc GCC          int             unsigned int           unsigned int
+ * kernel             int             unsigned int           unsigned long
+ */
+
+#ifdef __INT32_TYPE__
+#undef __INT32_TYPE__
+#define __INT32_TYPE__		int
+#endif
+
+#ifdef __UINT32_TYPE__
+#undef __UINT32_TYPE__
+#define __UINT32_TYPE__	unsigned int
+#endif
+
+#ifdef __UINTPTR_TYPE__
+#undef __UINTPTR_TYPE__
+#define __UINTPTR_TYPE__	unsigned long
+#endif
+
+#endif /* _UAPI_ASM_TYPES_H */
-- 
2.8.1

(unknown)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David

(unknown)

[Michelle Tortora]

We Give Out Loans For 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans, Email Us At jerryfunds11@inbox.lv<mailto:jerryfunds11@inbox.lv>  With Amount Needed And Phone Number.

(unknown)

[ngler]

[-- Attachment #1: EMAIL_7236410667_linux-parisc.zip --]
[-- Type: application/zip, Size: 2973 bytes --]

(unknown)

[jerryfunds12]

We Give Out Loans For 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans, Email Us At jerrysmith@inbox.lv  With Amount Needed And Phone Number.

(unknown)

[jerryfunds2]

We Give Out Loans For 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans, Email Us At j.funds2000000@inbox.lv  With Amount Needed And Phone Number.

(unknown)

[jerryfunds19]

We Give Out Loans For 3% Interest Rate And We Offer Loans From $5,000 To $50,000,000.00, Are You Looking To Buy A House Car Or Company Or Start Up A Truck Company or Buy A Truck Or Personal Loans, Email Us At j.funds2000000@inbox.lv  With Amount Needed And Phone Number.

(unknown)

[Mark Singer]

Do you need an investor?
Our investors fund project and business. We also give out loan/credit t=
o any individual and company at 3% interest rate yearly. For more infor=
mation, Contact us via Email: devonfps@gmail.com=20

If you need an investor or quick funding, forward your response ONLY to=
 this E-mail: devonfps@gmail.com=20
=2E...
Haben Sie einen Investor brauchen?
Unsere Investoren Fonds Projekt- und Gesch=E4fts. Wir geben auch Darleh=
en / Kredite an jeden einzelnen und Unternehmen bei 3% Zinsen j=E4hrlic=
h. F=FCr weitere Informationen, kontaktieren Sie uns per E-Mail: devonf=
ps@gmail.com=20

Wenn Sie ein Investor oder schnelle Finanzierung ben=F6tigen, senden Si=
e Ihre Antwort nur auf diese E-mail: devonfps@gmail.com --
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[Sasnett_Karen]

Haben Sie einen Investor brauchen?

Haben Sie gesch=E4ftliche oder pers=F6nliche Darlehen ben=F6tigen?

Wir geben Darlehen an eine nat=FCrliche Person und Unternehmen bei 3% Z=
insen j=E4hrlich. Weitere Informationen Kontaktieren Sie uns per E-Mail=
: omfcreditspa@hotmail.com<mailto:omfcreditspa@hotmail.com>



HINWEIS: Leiten Sie Ihre Antwort nur an diese E-Mail: omfcreditspa@hotm=
ail.com<mailto:omfcreditspa@hotmail.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(unknown)

[Unknown]

0x401cec20 <_ZSt8buf_cout>:     #   40948

00000000401ce000-00000000401e7000 rwxp 00000000000a7000 08:03 65295      /usr/lib/libstdc++.so.3.0.2

Albert, I assume you did install the new libstdc++3 as well?

apt-get works fine for me, btw (715/75 and a500), running apt 0.5.4


Albert's r2 was 401845ff:

0x401845f0 <_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecm+64>: stw r21,-6c(sr0,sp)
0x401845f4 <_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecm+68>: b,l 0x4018ec44 <_ZNSbIwSt11char_traitsIwESaIwEEC1Ev+1088>,rp
0x401845f8 <_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecm+72>: stw r20,-34(sr0,sp)
0x401845fc <_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecm+76>: copy r5,ret0
0x40184600 <_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecm+80>: copy r4,r19

which looks reasonable...

0x4018ec44 <_ZNSbIwSt11char_traitsIwESaIwEEC1Ev+1088>:  addil -1800,r19,%r1
0x4018ec48 <_ZNSbIwSt11char_traitsIwESaIwEEC1Ev+1092>:  ldw 5e8(sr0,r1),r21
0x4018ec4c <_ZNSbIwSt11char_traitsIwESaIwEEC1Ev+1096>:  bv r0(r21)
0x4018ec50 <_ZNSbIwSt11char_traitsIwESaIwEEC1Ev+1100>:  ldw 5ec(sr0,r1),r19

a .plt lookup, or something.


Richard

(unknown)

[Unknown]

    # safe-cvsimport assumes changes in newly-imported versions should *never*
    # be visible on the main trunk until explicitly placed there, usually by
    # a merge (cvs update -jx -jy).

Maybe someday I'll re-name it 'isolated-cvsimport'.  FYI in some cases
it's not handling upstream-removed files correctly.  No idea why this
changed or when I'll get interested enough to fix it.  For now I'll be
happy to consult and/or fix problems which result from safe-cvsimport.

	-P

(unknown)

[Unknown]

it seems that the installation dies before or when it tries to `branch
to kernel entry point 0x00100000'

Why might this be?

If I try booting from a serial console, over NFS or using rbootd will I
run into the same problem?

>From the email archive

http://lists.parisc-linux.org/pipermail/parisc-linux/2001-April/012249.html

I see that 710 machines appear to have problems with "interrupt routing
from the scsi and lan chips to the cpu". Could 705's have the same
problems (705's and 710's use the same scsi driver according to the
hardware database, so presumably they use at least very similar scsi
hardware), and is this the cause of my problem?

Any and all help will be gratefully received, on or off list.


Thanks in advance, Derek.

(unknown)

[Unknown]

...
P linux/arch/parisc/config.in
P linux/arch/parisc/defconfig
cvs server: Updating linux/arch/parisc/boot
cvs server: Updating linux/arch/parisc/boot/boot_code
cvs [server aborted]: cannot open directory /home/cvs/parisc/linux/arch/parisc/b
oot/boot_code: No such file or directory

Dave

-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)