Later versions of this controller also allow 4k pagesize,
so use mtd->writesize instead of a flag.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The main/spare areas are on different addresses on later versions
of the controller, so make them configurable.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The NAND controller has some limitations how to access the
internal buffers. It only allows 32 bit accesses. The driver
used to work around this by having special alignment aware
copy routines.
We now copy the whole page to a buffer in memory and let the
access functions use this buffer. This simplifies the driver.
A bonnie++ test showed that this has no negative performance
impact on the driver.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This factors the address cycle to a seperate function. This
becomes useful in a later patch where we can simplify the
command processing by making use of this function.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The oob layout was initialized several times. Instead, use
a smallpage layout by default and switch to a largepage
afterwards if necessary.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
The original Freescale driver used to have eccoob descriptions like
this:
static struct nand_ecclayout nand_hw_eccoob_8 = {
.eccbytes = 5,
.eccpos = {6, 7, 8, 9, 10},
.oobfree = {{0, 5}, {11, 5}}
};
static struct nand_ecclayout nand_hw_eccoob_16 = {
.eccbytes = 5,
.eccpos = {6, 7, 8, 9, 10},
.oobfree = {{0, 6}, {12, 4}}
};
The former was used for 8bit flashes and the latter for 16bit flashes.
They honored the fact that the bad block marker on 8bit flashes is on byte 5
while on 16bit flashes it is on byte 11.
In the Kernel driver this was copied wrong and we ended up with two identical
descriptions.
Change it so that we have only one description which leaves byte 5 and byte
11 unspecified so that it won't be used by others.
Also, rename the descriptions to nand_hw_eccoob_smallpage and
nand_hw_eccoob_largepage so that it can't be confused with Nand chip bus
widths (what actually happened in this driver)
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
This patch adds QE buffer descriptors mode support for the
spi_mpc8xxx driver, and as a side effect we now support CPM1
and CPM2 SPI controllers.
That means that today we support almost all MPC SPI controllers:
- MPC834x-style controllers (support PIO mode only);
- CPM1 and CPM2 controllers (support DMA mode only);
- QE SPI controllers in CPU mode (PIO mode with shift quirks);
- QE SPI controllers in buffer descriptors (DMA) mode;
The only controller we don't currently support is a newer eSPI
(with a dedicated chip selects and a bit different registers map).
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Soon there will be more flags introduced in subsequent patches, so
let's turn qe_mode into flags.
Also introduce mpc8xxx_spi_strmode() and print current SPI mode.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
We'll add more steps soon, so get rid of the duplication.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This patch fixes the following warning:
CC drivers/spi/spi_mpc8xxx.o
spi_mpc8xxx.c: In function 'of_mpc8xxx_spi_probe':
spi_mpc8xxx.c:681: warning: 'ret' may be used uninitialized in this function
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
This is needed to avoid ugly #ifdefs in drivers. Also update fsl_qe_udc
driver so that now it doesn't define its own versions that cause build
breakage when the generic stubs are used.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Add support for Wake on LAN (WOL) reception and waking the device up from
this signal via the ethtool interface. Currently we are only supporting
the magic-packet variant of wakeup.
WOL is enabled by specifying a second interrupt resource to the driver
which indicates where the interrupt for the WOL is being signalled. This
then enables the necessary ethtool calls to leave the device in a state
to receive WOL frames when going into suspend.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
The values of r_idx and rx_ring are not used after the last time they
are set in ixgbe_msix_clean_rx(), so they can be removed.
Signed-off-by: Ali Gholami Rudi <ali@rudi.ir>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We do not need to change the frame routing to direct all frames to the
management fifo during suspend. This is now done by the firmware.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Before calling gfar_clean_tx_ring() the driver grabs an irqsave
spinlock, and then tries to recycle skbs. But since
skb_recycle_check() returns 0 with IRQs disabled, we'll never
recycle any skbs.
It appears that gfar_clean_tx_ring() and gfar_start_xmit() are
mostly idependent and can work in parallel, except when they
modify num_txbdfree.
So we can drop the lock from most sections and thus fix the skb
recycling.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
gfar_error() can arrive at the middle of gfar_start_xmit() processing,
and so it can trigger transfers of BDs that we don't yet expect to
be transmitted.
Fix this by locking the tx queues in gfar_error().
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
We obviously want to write a modified 'temp' value back to the
register, not the saved IRQ flags.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fba4ed030c ("gianfar: Add Multiple
Queue Support") introduced the following build failure:
CC gianfar.o
gianfar.c: In function 'gfar_restore':
gianfar.c:1249: error: request for member 'napi' in something not a structure or union
This patch fixes the issue.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It is OK to poll with disabled IRQs, so remove the warning.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
To support PCIe hot plug in IOMMU, we register a notifier to respond to device
change action.
When the notifier gets BUS_NOTIFY_UNBOUND_DRIVER, it removes the device
from its DMAR domain.
A hot added device will be added into an IOMMU domain when it first does IOMMU
op. So there is no need to add more code for hot add.
Without the patch, after a hot-remove, a hot-added device on the same
slot will not work.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
The model for IOMMU passthrough is that decent devices that can cope
with DMA to all of memory get passthrough; crappy devices with a limited
dma_mask don't -- they get to use the IOMMU anyway.
This is done on the basis that IOMMU passthrough is usually wanted for
performance reasons, and it's only the decent PCI devices that you
really care about performance for, while the crappy 32-bit ones like
your USB controller can just use the IOMMU and you won't really care.
Unfortunately, the check for this was only looking at dev->dma_mask, not
at dev->coherent_dma_mask. And some devices have a 32-bit
coherent_dma_mask even though they have a full 64-bit dma_mask.
Even more unfortunately, fixing that simple oversight would upset
certain broken HP devices. Not only do they have a 32-bit
coherent_dma_mask, but they also have a tendency to do stray DMA to
unmapped addresses. And then they die when they take the DMA fault they
so richly deserve.
So if we do the 'correct' fix, it'll mean that affected users have to
disable IOMMU support completely on "a large percentage of servers from
a major vendor."
Personally, I have little sympathy -- given that this is the _same_
'major vendor' who is shipping machines which claim to have IOMMU
support but have obviously never _once_ booted a VT-d capable OS to do
any form of QA. But strictly speaking, it _would_ be a regression even
though it only ever worked by fluke.
For 2.6.33, we'll come up with a quirk which gives swiotlb support
for this particular device, and other devices with an inadequate
coherent_dma_mask will just get normal IOMMU mapping.
The simplest fix for 2.6.32, though, is just to jump through some hoops
to try to allocate coherent DMA memory for such devices in a place that
they can reach. We'd use dma_generic_alloc_coherent() for this if it
existed on IA64.
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Each device has its own 'recovery_offset' showing how far
recovery has progressed on the device.
As the only real significance of this is that fact that it can
be stored in the metadata and recovered at restart, and as
only 1.x metadata can do this, we were only updating
'recovery_offset' to 'curr_resync_completed' when updating
v1.x metadata.
But this is wrong, and we will shortly make limited use of this
field in v0.90 metadata.
So move the update into common code.
Signed-off-by: NeilBrown <neilb@suse.de>
Fix a type in rt2800_config_channel_rt3x. The second write to RF
register 2 should be to RF register 3. This is confirmed by the
legacy Ralink code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
fix some typos and punctuation in comments
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For my Linksys WUSB11 at76c503-i3861 device, scanning fails without
probe_delay, min_channel_time, and max_channel_time specified for the
scan request. These values were found by checking scan requests from
the at76_usb driver.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Acked-by: Kalle Valo <kalle.valo@iki.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
As mentioned on the linux-wireless mailing list, the current copyright
statements in the rt2x00 are meaningless, as the rt2x00 project is
not even a formal legal entity. Therefore it is better to replace
the existing copyright statements with copyright statements for the
people that actually wrote the code.
Note: Updated to the best of my knowledge with respect to who
contributed considerable amounts of code.
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
CC: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Link tuning code from the legacy rt2570 driver turned out to be
harmful and got disabled by the commit d06193f ("rt2x00: Disable
link tuning in rt2500usb") in August 2008.
There is no reason to keep this dead code any longer so remove it
(it can still be retrieved from the git history if necessary).
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is needed for at least RT3070 chip.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
eFuse EEPROM is used also by USB chips (i.e. RT3070)
so move the needed code from rt2800pci to rt2800lib.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Rename RXD_W0_* defines to RXINFO_W0_* ones to match naming
used for TX descriptor and by the vendor driver.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Add rf_vals tables and rt2800_probe_hw_mode() to rt2800lib.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Enclose interface specific code in rt2800[pci,usb]_probe_hw_mode()
with rt2x00_intf_is_[pci,usb]() checks.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Move hw_mode information initialization code block before
HT information initialization one to match the ordering used
by rt2800pci's rt2800pci_probe_hw_mode().
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rt2800pci's rf_vals[] copy was missing values for some channels.
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
