For many purposes, including interrupt-swizzling, devices with ARI
enabled behave as if they have one device (number 0) and 256 functions.
This probably hasn't bitten us in practice because all ARI devices I've
seen are also IOV devices, and IOV devices are required to use MSI.
This isn't guaranteed, and there are legitimate reasons to use ARI
without IOV, and hence potentially use pin-based interrupts.
Signed-off-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

There are 2 problems on mask states in suspend/resume.

[1]:
It is better to restore the mask states of MSI/MSI-X to initial states
(MSI is unmasked, MSI-X is masked) when we release the device.
The pci_msi_shutdown() does the restoration of mask states for MSI,
while the msi_free_irqs() does it for MSI-X.  In other words, in the
"disable" path both of MSI and MSI-X are handled, but in the "shutdown"
path only MSI is handled.

MSI:
   pci_disable_msi()
      => pci_msi_shutdown()
         [ mask states for MSI restored ]
         => msi_set_enable(dev, pos, 0);
      => msi_free_irqs()

MSI-X:
   pci_disable_msix()
      => pci_msix_shutdown()
         => msix_set_enable(dev, 0);
      => msix_free_all_irqs
         => msi_free_irqs()
            [ mask states for MSI-X restored ]

This patch moves the masking for MSI-X from msi_free_irqs() to
pci_msix_shutdown().

This change has some positive side effects:
 - It prevents OS from touching mask states before reading preserved
   bits in the register, which can be happen if msi_free_irqs() is
   called from error path in msix_capability_init().
 - It also prevents touching the register after turning off MSI-X in
   "disable" path, which can be a problem on some devices.

[2]:
We have cache of the mask state in msi_desc, which is automatically
updated when msi/msix_mask_irq() is called.  This cached states are
used for the resume.

But since what need to be restored in the resume is the states before
the shutdown on the suspend, calling msi/msix_mask_irq() from
pci_msi/msix_shutdown() is not appropriate.

This patch introduces __msi/msix_mask_irq() that do mask as same
as msi/msix_mask_irq() but does not update cached state, for use
in pci_msi/msix_shutdown().

[updated: get rid of msi/msix_mask_irq_nocache() (proposed by Matthew Wilcox)]
Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The initial state of mask register of MSI is unmasked.  We set it
masked before calling arch_setup_msi_irqs().  If arch_setup_msi_irq()
fails, it is better to restore the state of the mask register.
Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

These names are too long!  Drop _OFFSET to save some bytes/lines.
Reviewed-by: NMatthew Wilcox <willy@linux.intel.com>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The ALi loses some state if it goes into D3. Unfortunately even with the
chipset documents I can't figure out how to restore some bits of it.

The VIA one saves/restores apparently fine but the ACPI _GTM methods break
on some platforms if we do this and this causes cable misdetections.

These are both effectively regressions as historically nothing matched the
devices and then decided not to bind to them. Nowdays something is binding
to all sorts of devices and a result they get dumped into D3.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Add documentation for missing parameters in PCI hotplug code.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

For devices attached to the root bus, we can't trigger Secondary Bus
Reset because there is no bridge device associated with the bus. So
need to check bus->self again NULL first before using it.
Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NYu Zhao <yu.zhao@intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Acked-by: NAndrew Patterson <andrew.patterson@hp.com>
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

In current code it continues setup even if alloc_msi_entry() for MSI-X
is failed due to lack of memory.  It means arch_setup_msi_irqs() might
be called with msi_desc entries less than its argument nvec.

At least x86's arch_setup_msi_irqs() uses list_for_each_entry() for
dev->msi_list that suspected to have entries same numbers as nvec, and
it doesn't check the number of allocated vectors and passed arg nvec.
Therefore it will result in success of pci_enable_msix(), with less
vectors allocated than requested.

This patch fixes the error route to return -ENOMEM, instead of continuing
the setup (proposed by Matthew Wilcox).

Note that there is no iounmap in msi_free_irqs() if no msi_disc is
allocated.
Reviewed-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

FYI, there's a post-rc1 build regression with certain configs:

 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb166): undefined reference to `pci_hp_remove_module_link'
 drivers/built-in.o: In function `pci_hp_deregister':
 (.text+0xb19f): undefined reference to `pci_destroy_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb583): undefined reference to `pci_create_slot'
 drivers/built-in.o: In function `__pci_hp_register':
 (.text+0xb5b1): undefined reference to `pci_hp_create_module_link'
 make: *** [.tmp_vmlinux1] Error 1

Caused by:

| 2b121bc2 is first bad commit
| commit 2b121bc2
| Date:   Thu Jun 25 13:25:36 2009 +0200
|
|     eeepc-laptop: Register as a pci-hotplug device

which changed the driver to use the PCI hotplug infrastructure, but
didn't do a good job on the Kconfig rules.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NLen Brown <len.brown@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently we reinit the ldisc on final tty close which is what the old code
did to ensure that if the device retained its termios settings then it had the
right ldisc. tty_ldisc_reinit does that but also leaves us with the reset
ldisc reference which is then leaked.

At this point we know the port will be recycled so we can kill the ldisc
off completely rather than try and add another ldisc free up when the kref
count hits zero.

At this point it is safe to keep the ldisc closed as tty_ldisc waiting
methods are only used from the user side, and as the final close we are
the last such reference. Interrupt/driver side methods will always use the
non wait version and get back a NULL.

Found with kmemleak and investigated/identified by Catalin Marinas.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While testing the driver on PPC, we ran into a crash with LRO, Jumbo frames.
With CONFIG_PPC_64K_PAGES configured (a default in PPC), MAX_SKB_FRAGS drops to 3 and we were crossing the array limits on skb_shinfo(skb)->frags[].
Now we coalesce the frags from the same physical page into one slot in
skb_shinfo(skb)->frags[] and go to the next index when the frag is from

different physical page.

This patch is against the net-2.6 tree.
Signed-off-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sky2 driver on PowerPC targets floods kernel log with following errors:

  eth1: hw csum failure.
  Call Trace:
  [ef84b8a0] [c00075e4] show_stack+0x50/0x160 (unreliable)
  [ef84b8d0] [c02fa178] netdev_rx_csum_fault+0x3c/0x5c
  [ef84b8f0] [c02f6920] __skb_checksum_complete_head+0x7c/0x84
  [ef84b900] [c02f693c] __skb_checksum_complete+0x14/0x24
  [ef84b910] [c0337e08] tcp_v4_rcv+0x4c8/0x6f8
  [ef84b940] [c031a9c8] ip_local_deliver+0x98/0x210
  [ef84b960] [c031a788] ip_rcv+0x38c/0x534
  [ef84b990] [c0300338] netif_receive_skb+0x260/0x36c
  [ef84b9c0] [c025de00] sky2_poll+0x5dc/0xcf8
  [ef84ba20] [c02fb7fc] net_rx_action+0xc0/0x144

The NIC is Yukon-2 EC chip revision 1.

Converting checksum field from le16 to CPU byte order fixes the issue.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

- cleanup debug calls
- shorten function names
- cleanup error exit paths
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

amd64_check_ecc_enabled() returns non-zero status when ECC
checking/correcting is disabled and this fails further loading of the
driver even when 'ecc_enable_override' boot param is used.

Fix that by clearing return status in that case.
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Checking whether the machine is using ECC enabled DRAM is done through
testing the DimmEccEn bit in the DRAM Cfg Low register (F2x[1,0]90). Do
that instead of testing all bits from the DimmEccEn upwards.

Also, remove mci->edac_cap assignment and use value returned from
amd64_determine_edac_cap().
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>

Drop the e820 scanning and use existing function for finding valid
RAM regions to add to 1:1 mapping.
Signed-off-by: NChris Wright <chrisw@redhat.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>

Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:

Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc00000000001af64
Oops: Kernel access of bad area, sig: 11 [#1]

The wrong usage of "(void *)__pa(&temperature)" in rtas_call() is
removed by using the function rtas_get_sensor() which does the
right thing.
Signed-off-by: NAdrian Reber <adrian@lisas.de>
Acked-by: NUtz Bacher <utz.bacher@de.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
> On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
> > Sonny Rao writes:
> >
> > > Fix the BSR driver to allow small BSR devices, which are limited to a
> > > single 4k space, on a 64k page kernel.  Previously the driver would
> > > reject the mmap since the size was smaller than PAGESIZE (or because
> > > the size was greater than the size of the device).  Now, we check for
> > > this case use remap_4k_pfn(). Also, take out code to set vm_flags,
> > > as the remap_pfn functions will do this for us.
> >
> > Thanks.
> >
> > Do we know that the BSR size will always be 4k if it's not a multiple
> > of 64k?  Is it possible that we could get 8k, 16k or 32k or BSRs?
> > If it is possible, what does the user need to be able to do?  Do they
> > just want to map 4k, or might then want to map the whole thing?
>
>
> Hi Paul, I took a look at changing the driver to reject a request for
> mapping more than a single 4k page, however the only indication we get
> of the requested size in the mmap function is the vma size, and this
> is always one page at minimum.  So, it's not possible to determine if
> the user wants one 4k page or more.  As I noted in my first response,
> there is only one case where this is even possible and I don't think
> it is a significant concern.
>
> I did notice that I left out the check to see if the user is trying to
> map more than the device length, so I fixed that.  Here's the revised
> patch.

Alright, I've reworked this now so that if we get one of these cases
where there's a bsr that's > 4k and < 64k on a 64k kernel we'll only
advertise that it is a 4k BSR to userspace.  I think this is the best
solution since user programs are only supposed to look at sysfs to
determine how much can be mapped, and libbsr does this as well.

Please consider for 2.6.31 as a fix, thanks.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Add a 4096 byte BSR size which will be used on new machines.  Also, remove
the warning when we run into an unknown size, as this can spam the kernel
log excessively.
Signed-off-by: NSonny Rao <sonnyrao@us.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The macio_dev's created to map devices inside the MacIO ASICs
don't have proper dma_ops. This causes crashes on some machines
since the SCSI code calls dma_map_* on our behalf using the
device we hang from.

This fixes it by copying the parent PCI device dma_ops into
the macio_dev when creating it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468

When the ACPI video driver initializes, it does a namespace walk
looking for for supported devices. When we find an appropriate
handle, we walk up the ACPI tree looking for a PCI root bus, and
then walk back down the PCI bus, assuming that every device
inbetween is a P2P bridge.

This assumption is not correct, and is reported broken on at
least:

	Dell Latitude E6400
	ThinkPad X61
	Dell XPS M1330

Add a NULL deref check to prevent boot panics.
Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: NTroy Moure <twmoure@szypr.net>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NJanne Grunau <j@jannau.net>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

CMSG is an ACPI method used to find features available on
an Eee PC. But some features are never repported, even if present.

If the getter of a feature is present, this patch will set
the corresponding bit in cmsg.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

If there is there is no getter defined, get_acpi()
will return -ENODEV.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Refactor rfkill code, because we'll add another
rfkill for wwan3g later.
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

Convert the unusual printk(EEEPC_<level> uses to
the more standard pr_fmt and pr_<level>(.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Signed-off-by: NLen Brown <len.brown@intel.com>

The eee contains a logically (but not physically) hotpluggable PCIe slot.
Currently this is handled by adding or removing the PCI device in response
to rfkill events, but if a user has forced pciehp to bind to it (with the
force=1 argument) then both drivers will try to handle the event and
hilarity (in the form of oopses) will ensue. This can be avoided by having
eee-laptop register the slot as a hotplug slot. Only one of pciehp and
eee-laptop will successfully register this, avoiding the problem.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NCorentin Chary <corentincj@iksaif.net>
Tested-by: NDarren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Add missing GPL flag and description.

mdio: module license 'unspecified' taints kernel.
Disabling lock debugging due to kernel taint

Signed-off-by: Nicolas Reinecke <nr <at> das-labor.org>
Acked-by: NBen Hutchings <bhutchings@solarflare.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Unsigned boguscnt cannot be less than 0.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the case when ucc_geth or gianfar are compiled
as modules. Without this patch the call to phy_connect() fails.
Signed-off-by: NIonut Nicu <ionut.nicu@freescale.com>
Acked-by: NAndy Fleming <afleming@freescale.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This commit 335f8514 has stopped
properly checking if there is any usb serial associated with the tty in
the close function. It happens the close function is called by releasing
the terminal right after opening the device fails.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This commit 10077d4a has stopped
checking if there was a valid acm device associated to the tty, which is
not true right after open fails and tty subsystem tries to close the
device.

As an example, open fails with a non-existing device, when probe has
never been called, because the device has never been plugged. This is
common in systems with static modules and no udev.
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is required, otherwise a user will get a EINVAL while opening a
non-existing device, instead of ENODEV.

This is what I get with this patch applied now instead of an "Invalid
argument".

  cascardo@vespa:~$ cat /dev/ttyACM0
  cat: /dev/ttyACM0: No such device
  cascardo@vespa:~$
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This build error triggers on x86:

 drivers/built-in.o: In function `i2c_dw_init':
 i2c-designware.c:(.text+0x4e37ca): undefined reference to `clk_get_rate'
 drivers/built-in.o: In function `dw_i2c_probe':
 i2c-designware.c:(.devinit.text+0x51f5e): undefined reference to `clk_get'
 i2c-designware.c:(.devinit.text+0x51f76): undefined reference to `clk_enable'
 i2c-designware.c:(.devinit.text+0x520ff): undefined reference to `clk_disable'
 i2c-designware.c:(.devinit.text+0x52108): undefined reference to `clk_put'

Because this new driver uses the clk_*() facilities which is an
ARM-only thing currently.
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Tell PCI core that atl1* device can wakeup the system when WOL is
enabled by calling device_set_wakeup_enable.

Joerg noted that his atl1e device WOL fine after enabling it with
ethtool and changing /sys/class/net/eth0/device/power/wakeup to enabled
Tested on atl1e: https://bugzilla.novell.com/show_bug.cgi?id=493214

Tested by: Joerg Reuter <jreuter@novell.com>
Signed-off-by: NBrandon Philips <bphilips@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit ae0e8e82.

This change had two problems:

1) Since it frees the stats in the drivers' close method, we
   can OOPS in the transmit routine.

2) stats are no longer remembered across ifdown/ifup which
   disagrees with how every other device operates.

Thanks to analysis and test patch from Serge E. Hallyn
and initial OOPS report by Sachin Sant.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes and obvious typo in the netdev_ops initialization:
ndo_so_ioctl should be ndo_do_ioctl.
Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The existing code had the following race:

Thread-1                       Thread-2

inc/read in_use
                               inc/read in_use
inc tx_free_list[qos].len
                               inc tx_free_list[qos].len

The actual in_use value was incremented twice, but thread-1 is going
to free memory based on its stale value, and will free one too many
times.  The result is that memory is freed back to the kernel while
its packet is still in the transmit buffer.  If the memory is
overwritten before it is transmitted, the hardware will put a valid
checksum on it and send it out (just like it does with good packets).
If by chance the TCP flags are clobbered but not the addresses or
ports, the result can be a broken TCP stream.

The fix is to track the number of freed packets in a single location
(a Fetch-and-Add Unit register).  That way it can never get out of sync
with itself.

We try to free up to MAX_SKB_TO_FREE (currently 10) buffers at a time.
If fewer are available we adjust the free count with the difference.
The action of claiming buffers to free is atomic so two threads cannot
claim the same buffers.
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>