This is a simple gpiolib driver giving access to the GPIO lines in the
VIA framebuffer system.  A simple mechanism exists for switching lines
between GPIO and I2C, but it's only compile-time for now.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This patch moves data of interest into a new viafb_dev structure which
describes the device as a whole; the idea here is to create a separation
between what all devices may need and what the framebuffer device in
particular needs.

I've also made some small steps toward thinning out the global.h mess.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

The first step toward turning viafb into a multifunction driver.  This
patch creates a new via-core.c file which serves as the main PCI driver;
everything else comes below that.  Some work has been done to rationalize
the i2c drivers in this new scheme.

Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Cc: Harald Welte <laforge@gnumonks.org>
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

...otherwise it seems we run into conflicts with shadowy other users which
don't expect to see i2c taking control of ports it never used to do
anything with.
Reported-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

[jc: no signoff, added my own]
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This patch changes the way how the various I2C busses are used internally
inside the viafb driver:  Previosuly, only a single i2c_adapter was created,
even though two different hardware I2C busses are accessed: A structure member
in a global variable was modified to indicate the bus to be used.

Now, all existing hardware busses are registered with the i2c core, and the
viafb_i2c_{read,write}byte[s]() function take the adapter number as function
call parameter, rather than referring to the global structure member.

[jc: even more painful merge with mainline changes ->2.6.34]
[jc: painful merge with OLPC changes]

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NHarald Welte <HaraldWelte@viatech.com>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

[jc: extensive merge conflict fixes]
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NChris Ball <cjb@laptop.org>

This patch is a painful merge of change
a90bab567ece3e915d0ccd55ab00c9bb333fa8c0 (viafb: Add support for 2D
accelerated framebuffer on VX800/VX855) in the OLPC tree, originally by
Harald Welte.  Harald's changelog read:

	The VX800/VX820 and the VX855/VX875 chipsets have a different 2D
    	acceleration engine called "M1".  The M1 engine has some subtle
    	(and some not-so-subtle) differences to the previous engines, so
    	support for accelerated framebuffer on those chipsets was disabled
    	so far.

This merge tries to preserve Harald's changes in the framework of the
much-changed 2.6.34 viafb code.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This will help us for the upcoming support for 2D acceleration using
the M1 engine.

[jc: fixed merge conflicts]
Signed-off-by: NHarald Welte <HaraldWelte@viatech.com>

As suggested by Florian: make both mode-setting paths use the same code.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

Commit c3e25673 (viafb: 2D engine rewrite)
changed the setting of the GEMODE register so that the reserved bits are no
longer preserved.  Fix that; at the same time, move this code to its own
function and restore the use of symbolic constants.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This was part of Harald's "make viafb a first-class citizen using
pci_driver" patch, but somehow got dropped when that patch went into
mainline.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

This patch alters viafb to use the proper Linux in-kernel API to access
PCI configuration space, rather than poking at I/O ports by itself.

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NHarald Welte <HaraldWelte@viatech.com>

The current code executed from module_init() in viafb does not have
proper error checking and [partial] resoure release paths in case
an error happens half way through driver initialization.

This patch adresses the most obvious of those issues, such as a
leftover i2c bus if module_init (and thus module load) fails.

[jc: fixed merge conflicts]
[jc: also restored -ENOMEM return on ioremap() fail]

Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: ScottFang@viatech.com.cn
Cc: JosephChan@via.com.tw
Signed-off-by: NHarald Welte <HaraldWelte@viatech.com>

Official patch to fix the r8169 frame length check error.

Based on this initial thread:
http://marc.info/?l=linux-netdev&m=126202972828626&w=1
This is the official patch to fix the frame length problems in the r8169
driver.  As noted in the previous thread, while this patch incurs a performance
hit on the driver, its possible to improve performance dynamically by updating
the mtu and rx_copybreak values at runtime to return performance to what it was
for those NICS which are unaffected by the ideosyncracy (if there are any).

Summary:

    A while back Eric submitted a patch for r8169 in which the proper
allocated frame size was written to RXMaxSize to prevent the NIC from dmaing too
much data.  This was done in commit fdd7b4c3.  A
long time prior to that however, Francois posted
126fa4b9, which expiclitly disabled the MaxSize
setting due to the fact that the hardware behaved in odd ways when overlong
frames were received on NIC's supported by this driver.  This was mentioned in a
security conference recently:
http://events.ccc.de/congress/2009/Fahrplan//events/3596.en.html

It seems that if we can't enable frame size filtering, then, as Eric correctly
noticed, we can find ourselves DMA-ing too much data to a buffer, causing
corruption.  As a result is seems that we are forced to allocate a frame which
is ready to handle a maximally sized receive.

This obviously has performance issues with it, so to mitigate that issue, this
patch does two things:

1) Raises the copybreak value to the frame allocation size, which should force
appropriately sized packets to get allocated on rx, rather than a full new 16k
buffer.

2) This patch only disables frame filtering initially (i.e., during the NIC
open), changing the MTU results in ring buffer allocation of a size in relation
to the new mtu (along with a warning indicating that this is dangerous).

Because of item (2), individuals who can't cope with the performance hit (or can
otherwise filter frames to prevent the bug), or who have hardware they are sure
is unaffected by this issue, can manually lower the copybreak and reset the mtu
such that performance is restored easily.
Signed-off-by: NNeil Horman <nhorman@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Intel X58 have asc7621a chip. So added X58 entry in Kconfig for asc7621.
Also arranged existing models in ascending order.
Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

"ret" is used to store the return value for watchdog_trigger() and it
should be signed for the error handling to work.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Add missing newline to dev_warn() message string. This is more of an issue
with older kernels that don't automatically add a newline if it was missing
from the end of the previous line.
Signed-off-by: NDean Nelson <dnelson@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Avoid hex and decimal confusion when printing out the cpu model.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

FC disable is bit 3 of the txmac ctl register, but commit 6720949d
("Staging: et131x: Kil the txmac type") accidentally changed the code to
set bit 2 instead.
Signed-off-by: NNick Bowler <nbowler@draconx.ca>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit a20b2a44.

As requested by David Fries.  This makes CDROMs which are slave drives
on a ribbon without a master disappear and causes other similar kinds
of badness.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As reported by Stephen Rothwell.

drivers/net/tulip/uli526x.c: In function 'uli526x_rx_packet':
drivers/net/tulip/uli526x.c:861: warning: assignment makes pointer from integer without a cast
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using VT6410/6415/6330 chips on some VIA's platforms, the HDD
connection to VT6410/6415/6330 cannot be detected.

It is because the driver detects wrong via_isa_bridge ID, and then
causes this issue to happen.
Signed-off-by: NJoseph Chan <josephchan@via.com.tw>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This is quite similar to b39fe41f
though said registers are not even documented as 64-bit registers
- as opposed to the initial TxDescStartAddress ones - but as single
bytes which must be combined into 32 bits at the MMIO read/write
level before being merged into a 64 bit logical entity.

Credits go to Ben Hutchings <ben@decadent.org.uk> for the MAR
registers (aka "multicast is broken for ages on ARM) and to
Timo Teräs <timo.teras@iki.fi> for the MAC registers.
Signed-off-by: NFrancois Romieu <romieu@fr.zoreil.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

pcnet_cs:
 *add new id (Allied Telesis LM33-PCM-T Lan&Modem multifunction card)
 *use PROD_ID for LA-PCM.(because LA-PCM and LM33-PCM-T use the same MANF_ID).
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Round-robin (mode 0) does nothing to ensure that any multicast traffic
originally destined for the host will continue to arrive at the host when
the link that sent the IGMP join or membership report goes down.  One of
the benefits of absolute round-robin transmit.

Keeping track of subscribed multicast groups for each slave did not seem
like a good use of resources, so I decided to simply send on the
curr_active slave of the bond (typically the first enslaved device that
is up).  This makes failover management simple as IGMP membership
reports only need to be sent when the curr_active_slave changes.  I
tested this patch and it appears to work as expected.

Originally reported by Lon Hohberger <lhh@redhat.com>.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
CC: Lon Hohberger <lhh@redhat.com>
CC: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously the driver tweaked txqueuelen to avoid false Tx hang reports
seen at half duplex.  This had the effect of overriding user set values
on link change/reset. Testing shows that adjusting only the timeout
factor is sufficient to prevent Tx hang reports at half duplex.

This patch removes all instances of tx_queue_len in the driver.

Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>

CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When running the offline diagnostic tests check to see if any VFs are
online.  If so then only run the link test.  This is necessary because
the VFs running in guest VMs aren't aware of when the PF is taken
offline for a diagnostic test.  Also put a message to the system log
telling the system administrator to take the VFs offline manually if
(s)he wants to run a full diagnostic.  Return 1 on each of the tests
not run to alert the user of the condition.
Signed-off-by: NGreg Rose <gregory.v.rose@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

igb was previously checking the wrong bits in the MANC register to determine
if managability was enabled.  As a result it was incorrectly powering down and
resetting the phy when it didn't need to.
Signed-off-by: NAlexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix the following warnings:

be_ethtool.c:493: warning: integer constant is too large for 'long' type
be_ethtool.c:493: warning: integer constant is too large for 'long' type
Signed-off-by: NZhitong Wang <zhitong.wangzt@alibaba-inc.com>
Acked-by: NAjit Khaparde <ajitk@serverengines.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This reverts commit f931a5d5.

It causes regressions for some users.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously the driver tweaked txqueuelen to avoid false Tx hang reports seen at half duplex.
This had the effect of overriding user set values on link change/reset. Testing shows that
adjusting only the timeout factor is sufficient to prevent Tx hang reports at half duplex.

This patch removes all instances of tx_queue_len in the driver.

Originally reported and patched by Franco Fichtner
CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Previously the driver tweaked txqueuelen to avoid false Tx hang reports seen at half duplex.
This had the effect of overriding user set values on link change/reset. Testing shows that
adjusting only the timeout factor is sufficient to prevent Tx hang reports at half duplex.

Based on e1000e patch by Franco Fichtner <franco@lastsummer.de>

CC: Franco Fichtner <franco@lastsummer.de>
Signed-off-by: NEmil Tantilov <emil.s.tantilov@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Acked-by: NGrant Grundler <grundler@parisc-linux.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix undo of reserve() before RX recycle

gfar_new_skb reserve()s space in the SKB to align it.  If an error occurs,
and the skb needs to be returned to the RX recycle queue, the current code
attempts to reset head, but did not reset tail.  This patch remembers the
alignment amount, and reverses the reserve() when needed.
Signed-off-by: NBen Menchaca <ben@bigfootnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

During FCF solicitation, the switch is supposed to pad the
solicited advertisement out to the endpoints specified
maximum FCoE frame size.  That means that we need to receive
FIP frames that are larger than the standard MTU.  To make
sure the receive queue is configured correctly, we should be
filtering FIP traffic into the FCoE queues.
Signed-off-by: NChris Leech <christopher.leech@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently FIP (FCoE Initialization Protocol) frames
are going untagged. This causes various problems
with FCFs (switches) that have negotiated a priority
over dcbx. This patch tags FIP frames with the same
priority as the FCoE frames.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NChris Leech <christopher.leech@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If the user buffer count was 256 the shift would place a 1
in the offset region leading to errors. It also overwrites
the uers buffer list. This patch makes sure that at most
256 user buffers are allowed for DDP and the buffer count
is masked properly such that it doesn't overwrite the offset
when shifting the bits.
Signed-off-by: NRobert Love <robert.w.love@intel.com>
Signed-off-by: NYi Zou <yi.zou@intel.com>
Signed-off-by: NFrank Zhang <frank_1.zhang@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the last patch I missed an unecessary min_t comparison.
This patch removes it, the path allocates at most
72 tx queues for 82599 and 24 for 82598 there is no need
for this check.

Additionally this sets MAX_[TX|RX]_QUEUES to 72.  Which is
used as the size for the tx/rx_ring arrays. There is no
reason to have more tx_rings/rx_rings then num_tx_queues.
Signed-off-by: NJohn Fastabend <john.r.fastabend@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>