PCI: Use cached MSI cap while enabling MSI interrupts

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>
PCI: Use cached MSI-X cap while enabling MSI-X

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>
PCI: Clean up MSI/MSI-X capability #defines

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>
PCI: Use cached MSI/MSI-X offsets from dev, not from msi_desc

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>
PCI: Drop msi_control_reg() macro and use PCI_MSI_FLAGS directly

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>
PCI: Drop msi_lower_address_reg() and msi_upper_address_reg() macros

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>
PCI: Drop msi_data_reg() macro

msi_data_reg() doesn't provide any useful abstraction, so drop it.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI: Drop is_64bit_address() and is_mask_bit_support() macros

is_64bit_address() and is_mask_bit_support() don't provide any useful
abstraction, so drop them.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI: Drop msix_table_offset_reg() and msix_pba_offset_reg() macros

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>
PCI: Use msix_table_size() directly, drop multi_msix_capable()

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>
PCI: Drop msi_mask_reg() and remove drivers/pci/msi.h

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>
PCI: Use PCI_MSIX_TABLE_BIR, not PCI_MSIX_FLAGS_BIRMASK

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>
PCI: Remove "extern" from function declarations

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>
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.
USB: ftdi_sio: correct ST Micro Connect Lite PIDs

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>
USB: serial: option: Added support Olivetti Olicard 145

This adds PID for Olivetti Olicard 145 in option.c

Signed-off-by: Filippo Turato <nnj7585@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb-storage: CY7C68300A chips do not support Cypress ATACB

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>
USB: Fix initconst in ehci driver

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>
usb: phy: phy core cannot yet be a module

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>
mei: reduce flow control only for completed messages

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>