A few debug messages were missing newlines, add them
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We were testing hsotg pointer for null after we had already
dereferenced it
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 'bustype' in the boardinfo is not used. Remove it.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Only the ISA versions of the LabPC boards support DMA and the
devpriv->dma_chan is only set during the ISA board attach if
DMA is available. The extra check of the board->bustype is not
necessary in labpc_ai_cmd().
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The PCI and PCMCIA LabPC boards use shared interrupts and need the
IRQF_SHARED flag set when requesting the irq, the ISA boards do not.
Instead of checking the 'bustype' in labpc_common_attach() in order
to determine the isr_flags, just pass the flags as a parameter to the
function.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Only the ISA versions of the LabPC boards support DMA. Move the DMA
initialization out of the labpc_common_attach() and put it in the
ISA specific labpc_attach() function.
Remove the 'dma_chan' parameter from labpc_common_attach().
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently the ni_labpc driver is used by the legacy (ISA), PCI, and
PCMCIA versions of the LabPC board. The driver is enabled under the
COMEDI_PCI_DRIVERS section of the Kconfig. This means that PCI support
must be enabled in order to use the ni_labpc driver for the PCI or
PCMCIA drivers.
Split the PCI support code out of the ni_labpc driver into a separate
driver, ni_labpc_pci. The PCMCIA support is already slip out as
ni_labpc_cs.
Modify the Kconfig so that the common code in ni_labpc is enabled by the
Kconfig option COMEDI_NI_LABPC. The ISA support code is currently still
in the ni_labpc driver but is only compiled in if COMEDI_NI_LABPC_ISA is
also enabled.
This allows the PCI and PCMCIA drivers to be enabled without the need
for the ISA stuff.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On ARM, it is not legal to pass values larger than 2ms into udelay(),
and mdelay() must be used instead, to avoid this build error:
ERROR: "__bad_udelay" [drivers/staging/comedi/drivers/daqboard2000.ko]
undefined!
On a related note, any use of mdelay() or large udelay() numbers should
be carefully reviewed, and replaced with msleep() or a different
implementation that does not rely on delaying the work.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The serio code can be a loadable module, which in turn means that nvec
also has to be a module, so mark it as "tristate" in Kconfig.
drivers/built-in.o: In function `nvec_mouse_remove':
drivers/staging/nvec/nvec_ps2.c:136: undefined reference to `serio_unregister_port'
drivers/built-in.o: In function `nvec_mouse_probe':
drivers/staging/nvec/nvec_ps2.c:126: undefined reference to `__serio_register_port'
drivers/built-in.o: In function `nvec_ps2_notifier':
drivers/staging/nvec/nvec_ps2.c:84: undefined reference to `serio_interrupt'
drivers/staging/nvec/nvec_ps2.c:91: undefined reference to `serio_interrupt'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Building zsmalloc as a module does not work on ARM because it uses
an interface that is not exported:
ERROR: "flush_tlb_kernel_range" [drivers/staging/zsmalloc/zsmalloc.ko] undefined!
Since this is only used as a performance optimization and only on ARM,
we can avoid the problem simply by not using that optimization when
building zsmalloc it is a loadable module.
flush_tlb_kernel_range is often an inline function, but out of the
architectures that use an extern function, only powerpc exports
it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver was merged in 2.6.38 but never actually compiled because
it depends on the <mach/pcie.h> header that has not made it into the
kernel. Starting with Linux-3.10, this results in "allyesconfig"
build errors, since spear13xx can now be enabled with the default
"multiplatform" platform on ARM. Let's mark it as broken for now.
If it doesn't get fixed, we can drop it completely.
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Viresh Kumar <viresh.kumar@st.com>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If krealloc() returns NULL, it doesn't free the original. So any code
of the form 'foo = krealloc(foo, ...);' is almost certainly a bug.
Introduced by commit fcb136e1ac5774909e0d85189f721b8dfa800e0f(mei: fix
reading large reposnes)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fixes bug when only first chunk of a large message split
by hbuf_max_len is written to the hardware.
All the consequent chunks will not get a new credit.
A regression introduced by the commit
0ef319c93cebff9f82bdd0cdbb298f2dd00acda8
mei: streamline write complete flow function
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A lot of platform code calls into the usb phy core at the moment, which
does not work if it is built as a loadable module. This will hopefully
change when those platforms are all converted to DT based probing,
but for now, the easiest solution is to change it from "tristate"
to "bool".
This solves at least these ARM allmodconfig build errors:
arch/arm/mach-imx/built-in.o: In function `imx_otg_ulpi_create':
arch/arm/mach-imx/ulpi.c:117: undefined reference to `otg_ulpi_create'
arch/arm/mach-omap2/built-in.o: In function `usbhs_init_phys':
arch/arm/mach-omap2/usb-host.c:652: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap_2430sdp_init':
arch/arm/mach-omap2/board-2430sdp.c:236: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap3_beagle_init':
arch/arm/mach-omap2/board-omap3beagle.c:554: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `devkit8000_init':
arch/arm/mach-omap2/board-devkit8000.c:596: undefined reference to `usb_bind_phy'
arch/arm/mach-omap2/built-in.o: In function `omap_ldp_init':
arch/arm/mach-omap2/board-ldp.c:379: undefined reference to `usb_bind_phy'
drivers/built-in.o: In function `ab8500_charger_probe':
drivers/power/ab8500_charger.c:3629: undefined reference to `usb_get_phy'
drivers/power/ab8500_charger.c:3706: undefined reference to `usb_put_phy'
drivers/built-in.o: In function `ab8500_charger_remove':
drivers/power/ab8500_charger.c:3411: undefined reference to `usb_put_phy'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix some of the initconst markings in the ehci driver(s).
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Many cards based on CY7C68300A/B/C use the USB ID 04b4:6830 but only the
B and C variants (EZ-USB AT2LP) support the ATA Command Block
functionality, according to the data sheets. The A variant (EZ-USB AT2)
locks up if ATACB is attempted, until a typical 30 seconds timeout runs
out and a USB reset is performed.
https://bugs.launchpad.net/bugs/428469
It seems that one way to spot a CY7C68300A (at least where the card
manufacturer left Cypress' EEPROM default vaules, against Cypress'
recommendations) is to look at the USB string descriptor indices.
A http://media.digikey.com/pdf/Data%20Sheets/Cypress%20PDFs/CY7C68300A.pdf
B http://www.farnell.com/datasheets/43456.pdf
C http://www.cypress.com/?rID=14189
Note that a CY7C68300B/C chip appears as CY7C68300A if it is running
in Backward Compatibility Mode, and if ATACB would be supported in this
case there is anyway no way to tell which chip it really is.
For 5 years my external USB drive has been locking up for half a minute
when plugged in and ata_id is run by udev, or anytime hdparm or similar
is run on it.
Finally looking at the /correct/ datasheet I think I found the reason. I
am aware the quirk in this patch is a bit hacky, but the hardware
manufacturers haven't made it easy for us.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The current ST Micro Connect Lite uses the FT4232H hi-speed quad USB
UART FTDI chip. It is also possible to drive STM reference targets
populated with an on-board JTAG debugger based on the FT2232H chip with
the same STMicroelectronics tools.
For this reason, the ST Micro Connect Lite PIDs should be
ST_STMCLT_2232_PID: 0x3746
ST_STMCLT_4232_PID: 0x3747
Signed-off-by: Adrian Thomasset <adrian.thomasset@st.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are some late urgent fixes for v3.10 merge window.
All of these errors were introduced by recent commits
which are in linux-next.
f_obex, multi and cdc2 gadget drivers have learned to
return a proper error code when something goes wrong.
usb_bind_phy() was mistakenly placed into .init.text
section which caused Section mismatch warnings and undefined
reference compile errors.
f_source_sink had a copy-paste error which is now corrected.
g_zero got a memory leak plugged.
Two defconfigs got fixed to enable the newly introduced
CONFIG_USB_PHY.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRdnDhAAoJEIaOsuA1yqRE2UoP/RakEoDFlC58D1FtiKYtedT+
/dyq6BA0riqLcOXbLKtvgG58G7KZGKzMWxCvsGALrbUSWRjRptN7Z7okx0onJgPr
Wfc6tgJwEQdBaH25FYWDJSZ+zoB7l+LYuEO5XstFE6A26Fa4xKudEf6OFr5/odgm
DRxwV0dOSsNzw9zjrDoTnEfLJe8aolGkQNOf/1FUCpLNGFRBt9qg1uMOs5P7bKdp
M544LVQSXjwWlqW1oyysUXBbjQtCK2QvELqa+3EK8yMCQQZ27lJzdgHml02NbyfE
ktoNB8w9hv4xxUIICgWcWQGPpx/1keE4K0xIycRpCTfQobNOcLv1gzxlZBmaXKQE
uBUnXqZ52DgSRMEBmqOOuZqvy5fYOX2e5WRlZNlXAYtnHWMTVf86SwHSr1EWhP7M
JLv2dvukagfkg6vlim4pkLEesLEqdzDK3aUMHCYZTQSTATUrV81CAeXZp1ZGVqCw
y8jF+UPGTCfnar9V9sGBWmye8Aj5Y1XMacWxsrUNiWXgI4kUTyFK3wwGKbeCihyI
z8uZnkTSTUck95S67UBol2dnAyJaEi5N+ttEW8TTyWmCkXmbCORT7wj8CQ6RAMnF
3cLRhU1BKqENaRaBYvVPH28kNSmjNxHQFoxesfDVmzzqUoEvVnzRP+NqLi8y3aSl
5HO3rg8pSc2j056sLLg9
=UKZz
-----END PGP SIGNATURE-----
Merge tag 'usb-for-v3.10-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next
Felipe writes:
usb: urgent fixes for v3.10 merge window
Here are some late urgent fixes for v3.10 merge window.
All of these errors were introduced by recent commits
which are in linux-next.
f_obex, multi and cdc2 gadget drivers have learned to
return a proper error code when something goes wrong.
usb_bind_phy() was mistakenly placed into .init.text
section which caused Section mismatch warnings and undefined
reference compile errors.
f_source_sink had a copy-paste error which is now corrected.
g_zero got a memory leak plugged.
Two defconfigs got fixed to enable the newly introduced
CONFIG_USB_PHY.
We had an inconsistent mix of using and omitting the "extern" keyword
on function declarations in header files. This removes them all.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI_MSIX_FLAGS_BIRMASK is mis-named because the BIR mask is in the
Table Offset register, not the flags ("Message Control" per spec)
register.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
msi_mask_reg() doesn't provide any useful abstraction, do drop it.
Remove the now-empty drivers/pci/msi.h.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The users of multi_msix_capable() are really interested in the table
size, so just say what we mean.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
msix_table_offset_reg() is used only once and adds a useless indirection,
so just use the table offset directly.
msix_pba_offset_reg() is unused, so just delete it.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
msi_lower_address_reg() and msi_upper_address_reg() don't provide any
useful abstraction, so drop them.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Note the error in pci_msix_table_size() -- we used PCI_MSI_FLAGS to
locate the PCI_MSIX_FLAGS word. No actual breakage because PCI_MSI_FLAGS
and PCI_MSIX_FLAGS happen to be the same.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
We always know the type (MSI vs MSI-X), so we can use the correct
cached capability offset rather than relying on the copy in the
msi_attrib.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
This doesn't change any existing symbols, but it puts them in logical
order and uses explicit masks instead of shifts, like the rest of the
file.
It also adds new symbols for PCI_MSIX_TABLE_BIR,
PCI_MSIX_TABLE_OFFSET, PCI_MSIX_PBA_BIR, and PCI_MSIX_PBA_OFFSET to
replace the mis-named PCI_MSIX_FLAGS_BIRMASK (the BAR index fields
are part of the Table and PBA registers, not the flags register).
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The patch uses the cached MSI-X capability offset in
pci_dev instead of reading it from config space when enabling
MSI-X interrupts.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The patch uses the cached MSI capability offset in pci_dev instead
of reading it from config space when enabling MSI interrupts.
[bhelgaas: removed unrelated msi_control_reg() changes]
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The function pci_msi_check_device() is called while enabling MSI
or MSI-X interrupts to make sure the PCI device can support MSI
or MSI-X capability. This patch removes the check on MSI or MSI-X
capability in the function and lets the caller do the check.
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The patch caches the MSI and MSI-X capability offset in PCI device
(struct pci_dev) so that we needn't read it from the config space
upon enabling or disabling MSI or MSI-X interrupts.
[bhelgaas: moved pm_cap size change to separate patch]
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The Power Management Capability (PCI_CAP_ID_PM == 0x01) is defined by PCI
and must appear in the 256-byte PCI Configuration Space from 0-0xff. It
cannot be in the PCIe Extended Configuration space from 0x100-0xfff, so
we only need a u8 to hold its offset.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit de88cbb7 moved definitions of chained_irq_enter and
chained_irq_exit to a generic header, which must be now included instead
of the legacy arch-specific one.
This patch fixes build error caused by including the legacy header
leading to undefined chained_irq_enter and chained_irq_exit symbols.
Signed-off-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY
be a sub-item of menuconfig symbol USB_PHY. This change gets the
selection of CONFIG_USB_MXS_PHY in mxs_defconfig lost. Hence the
boot stops at the point below.
[ 1.600867] ci_hdrc ci_hdrc.0: doesn't support gadget
[ 1.606282] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.613522] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to
work.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Commit edc7cb2 (usb: phy: make it a menuconfig) makes USB_MXS_PHY
be a sub-item of menuconfig symbol USB_PHY. This change gets the
selection of CONFIG_USB_MXS_PHY in imx_v6_v7_defconfig lost. Hence the
boot stops at the point below.
ci_hdrc ci_hdrc.0: doesn't support gadget
ci_hdrc ci_hdrc.0: EHCI Host Controller
ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
Add CONFIG_USB_PHY to have the CONFIG_USB_MXS_PHY selection back to
work.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The symbol usb_bind_phy is exported and annotated __init.
It looks like section mismatch. Fix by removing the
__init annotation of usb_bind_phy.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
If function instances are not put on gadget's unbind, their implementation
module's refcount is nonzero and it is impossible to unload them.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
acm was the first function to be converted and it seems that its
code served as a base for converting f_sourcesink to the new function
interface. source_sink has nothing to do with acm, though.
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Introduced by commit 29a664 (usb: gadget: cdc2: use function
framework for ACM)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Introduced by commit 59835a (usb: gadget: multi: use
function framework for ACM.)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Kay Sievers reported that coreutils' stat tool has a problem with
s390's statfs[64] definition:
> The definition of struct statfs::f_type needs a fix. s390 is the only
> architecture in the kernel that uses an int and expects magic
> constants lager than INT_MAX to fit into.
>
> A fix is needed to make Fedora boot on s390, it currently fails to do
> so. Userspace does not want to add code to paper-over this issue.
[...]
> Even coreutils cannot handle it:
> #define RAMFS_MAGIC 0x858458f6
> # stat -f -c%t /
> ffffffff858458f6
>
> #define BTRFS_SUPER_MAGIC 0x9123683E
> # stat -f -c%t /mnt
> ffffffff9123683e
The bug is caused by an implicit sign extension within the stat tool:
out_uint_x (pformat, prefix_len, statfsbuf->f_type);
where the format finally will be "%lx".
A similar problem can be found in the 'tail' tool.
s390 is the only architecture which has an int type f_type member in
struct statfs[64]. Other architectures have either unsigned ints or
long values, so that the problem doesn't occur there.
Therefore change the type of the f_type member to unsigned int, so
that we get zero extension instead of sign extension when assignment to
a long value happens.
This patch changes the s390 uapi struct stafs[64] definition in the kernel
to contain only unsigned values.
This was true for 32 bit builds anyway, since we use the generic uapi
header file in that case. So lets not include conditionally the generic
uapi header file but have the s390 implementation completely independent.
Also fix the types of struct compat_stafs to match reality and move the
definition of struct compat_statfs64 to asm/compat.h since it is not part
of the api.
Reported-by: Kay Sievers <kay@vrfy.org>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
For offset > PAGE_SIZE, s390_dma_map_pages() will issue a warning
and return a wrong dma address.
This patch removes the warning and fixes the dma return address
calculation.
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The compat definitions are not part of the uapi. So move them to
s390's private compat header file.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Fix this one for !COMPAT:
compat.h: In function ‘arch_compat_alloc_user_space’:
compat.h:292:2: error: implicit declaration of function ‘is_compat_task’
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The f_spare field within struct compat_statfs is four bytes larger
than within the native 31 bit struct statfs.
compat_sys_statfs() clears the f_spare field in user space which
means that in compat mode four bytes that are behind the user space
supplied struct compat_statfs will be corrupted (zeroed).
According to Thomas Gleixner's Linux 2.6 history tree this bug is
present since v2.5.74 87880da124 "[PATCH] s390: 31 bit compat.".
So it get's fixed shortly before its 10th anniversary. Tough luck.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
