Hook up of_platform_bus_probe with the cell platform in order to publish
the non-PCI devices in the device-tree of cell blades as of_platform_device(s)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch first splits of_device.c and of_platform.c, the later containing
the bits relative to of_platform_device's. On the "breaks" side of things,
drivers uisng of_platform_device(s) need to include asm/of_platform.h now
and of_(un)register_driver is now of_(un)register_platform_driver.
In addition to a few utility functions to locate of_platform_device(s),
the main new addition is of_platform_bus_probe() which allows the platform
code to trigger an automatic creation of of_platform_devices for a whole
tree of devices.
The function acts based on the type of the various "parent" devices encountered
from a provided root, using either a default known list of bus types that can be
"probed" or a passed-in list. It will only register devices on busses matching
that list, which mean that typically, it will not register PCI devices, as
expected (since they will be picked up by the PCI layer).
This will be used by Cell platforms using 4xx-type IOs in the Axon bridge
and can be used by any embedded-type device as well.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Add support for southbridges using the MPIC interrupt controller to
the native cell platforms.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch applies on top of the MPIC DCR support. It makes the MPIC
driver capable of a lot more auto-configuration based on the device-tree,
for example, it can retreive it's own physical address if not passed as
an argument, find out if it's DCR or MMIO mapped, and set the BIG_ENDIAN
flag automatically in the presence of a "big-endian" property in the
device-tree node.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch implements support for DCR based MPIC implementations. Such
implementations have the MPIC_USES_DCR flag set and don't use the phys_addr
argument of mpic_alloc (they require a valid dcr mapping in the device node)
This version of the patch can use a little bif of cleanup still (I can
probably consolidate rb->dbase/doff, at least once I'm sure on how the
hardware is actually supposed to work vs. possible simulator issues) and
it should be possible to build a DCR-only version of the driver. I need
to cleanup a bit the CONFIG_* handling for that and probably introduce
CONFIG_MPIC_MMIO and CONFIG_MPIC_DCR.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch makes the EMAC driver use the new DCR access methods. It
doesn't yet uses dcr_map() and thus still only work with real DCRs.
This will be fixed in a later patch
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch adds new dcr_map/dcr_read/dcr_write accessors for DCRs that
can be used by drivers to transparently address either native DCRs or
memory mapped DCRs. The implementation for memory mapped DCRs is done
after the binding being currently worked on for SLOF and the Axon
chipset. This patch enables it for the cell native platform
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
These were inherited from ARCH=ppc, but are not needed since parsing of interrupts
should be done via the of_* functions (who can do swizzling). If we ever need to
do non-standard swizzling on bridges without a device-node, then we might add
back a slightly different version of ppc_md.pci_swizzle but for now, that is not
the case.
I removed the couple of calls for these in 83xx. If that breaks something, then
there is a problem with the device-tree on these.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This patch reworks the way IRQs are fixed up on PCI for arch powerpc.
It makes pci_read_irq_line() called by default in the PCI code for
devices that are probed, and add an optional per-device fixup in
ppc_md for platforms that really need to correct what they obtain
from pci_read_irq_line().
It also removes ppc_md.irq_bus_setup which was only used by pSeries
and should not be needed anymore.
I've also removed the pSeries s7a workaround as it can't work with
the current interrupt code anyway. I'm trying to get one of these
machines working so I can test a proper fix for that problem.
I also haven't updated the old-style fixup code from 85xx_cds.c
because it's actually buggy :) It assigns pci_dev->irq hard coded
numbers which is no good with the new IRQ mapping code. It should
at least use irq_create_mapping(NULL, hard_coded_number); and possibly
also set_irq_type() to set them as level low.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Allow architectures to provide their own implementation of the big endian MMIO
accessors and "repeat" MMIO accessors for use by the generic iomap.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
More-or-less-tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The following patch fixes the failure of sunhme drivers on x86 hosts
due to missing pci_enable_device() and pci_set_master() calls, lost
during code refactoring. It has been filed as bugzilla bug #7502 [0]
and Debian bug #397460 [1].
[0] http://bugzilla.kernel.org/show_bug.cgi?id=7502
[1] http://bugs.debian.org/397460
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
It's bitrotten, long unmaintained, long hidden under BROKEN_ON_SMP,
etc. As scheduled in feature-removal-schedule.txt, and ack'd several
times on lkml.
Signed-off-by: Jeff Garzik <jeff@garzik.org>
Since we never checked the ->family value of templates
before, many applications simply leave it at zero.
Detect this and fix it up to be the pol->family value.
Also, do not clobber xp->family while reading in templates,
that is not necessary.
Signed-off-by: David S. Miller <davem@davemloft.net>
Two thirds of packets are lost because of misalignment. Users of
Asus laptop did apparently not notice it.
Reported on Gigabyte GA-945GM-S2.
Fix for http://bugzilla.kernel.org/show_bug.cgi?id=7517
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
The 8110SB based n2100 board signals a lot of what ought to be
PCI data parity errors durint operation of the 8169 as target.
Experiment proved that the driver can ignore the error and
process the packet as if nothing had happened.
Let's add an ad-hoc knob to enable users to fix their system while
avoiding the risks of a wholesale change.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Mostly taken from Realtek's driver.
It's a bit yucky but the original is even worse.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
With async scanning, we're now tripping the BUG_ON in
sas_ex_discover_end_dev(), so make the error handling here correct.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
XScale cores either have a DSP coprocessor (which contains a single
40 bit accumulator register), or an iWMMXt coprocessor (which contains
eight 64 bit registers.)
Because of the small amount of state in the DSP coprocessor, access to
the DSP coprocessor (CP0) is always enabled, and DSP context switching
is done unconditionally on every task switch. Access to the iWMMXt
coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
first issued, and iWMMXt context switching is done lazily.
CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
have iWMMXt support', but boards are supposed to select this config
symbol by hand, and at least one pxa27x board doesn't get this right,
so on that board, proc-xscale.S will incorrectly assume that we have a
DSP coprocessor, enable CP0 on boot, and we will then only save the
first iWMMXt register (wR0) on context switches, which is Bad.
This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
might have iWMMXt support, and we will enable iWMMXt context switching
if it does.' This means that with this patch, running a CONFIG_IWMMXT=n
kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
state over context switches, and running a CONFIG_IWMMXT=y kernel on a
non-iWMMXt capable CPU will still do DSP context save/restore.
These changes should make iWMMXt work on PXA3xx, and as a side effect,
enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
as well as setting and using HWCAP_IWMMXT properly.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This replaces the linear search algorithm for reverse lookup with
binary search.
It has the advantage of better scalability: O(log2(N)) instead of O(N).
This means that the average number of iterations is reduced from 250
(linear search if each value appears equally likely) down to at most 9.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This patch deprecates the existing use of an arbitrary value TFRC_SMALLEST_P
for low-threshold values of p. This avoids masking low-resolution errors.
Instead, the code now checks against real boundaries (implemented by preceding
patch) and provides warnings whenever a real value falls below the threshold.
If such messages are observed, it is a better solution to take this as an
indication that the lookup table needs to be re-engineered.
Changelog:
----------
This patch
* makes handling all TFRC resolution errors local to the TFRC library
* removes unnecessary test whether X_calc is 'infinity' due to p==0 -- this
condition is already caught by tfrc_calc_x()
* removes setting ccid3hctx_p = TFRC_SMALLEST_P in ccid3_hc_tx_packet_recv
since this is now done by the TFRC library
* updates BUG_ON test in ccid3_hc_tx_no_feedback_timer to take into account
that p now is either 0 (and then X_calc is irrelevant), or it is > 0; since
the handling of TFRC_SMALLEST_P is now taken care of in the tfrc library
Justification:
--------------
The TFRC code uses a lookup table which has a bounded resolution.
The lowest possible value of the loss event rate `p' which can be
resolved is currently 0.0001. Substituting this lower threshold for
p when p is less than 0.0001 results in a huge, exponentially-growing
error. The error can be computed by the following formula:
(f(0.0001) - f(p))/f(p) * 100 for p < 0.0001
Currently the solution is to use an (arbitrary) value
TFRC_SMALLEST_P = 40 * 1E-6 = 0.00004
and to consider all values below this value as `virtually zero'. Due to
the exponentially growing resolution error, this is not a good idea, since
it hides the fact that the table can not resolve practically occurring cases.
Already at p == TFRC_SMALLEST_P, the error is as high as 58.19%!
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This
* adds documentation about the lowest resolution that is possible within
the bounds of the current lookup table
* defines a constant TFRC_SMALLEST_P which defines this resolution
* issues a warning if a given value of p is below resolution
* combines two previously adjacent if-blocks of nearly identical
structure into one
This patch does not change the algorithm as such.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
1) For the forward X_calc lookup, it
* protects effectively against RTT=0 (this case is possible), by
returning the maximal lookup value instead of just setting it to 1
* reformulates the array-bounds exceeded condition: this only happens
if p is greater than 1E6 (due to the scaling)
* the case of negative indices can now with certainty be excluded,
since documentation shows that the formulas are within bounds
* additional protection against p = 0 (would give divide-by-zero)
2) For the reverse lookup, it warns against
* protects against exceeding array bounds
* now returns 0 if f(p) = 0, due to function definition
* warns about minimal resolution error and returns the smallest table
value instead of p=0 [this would mask congestion conditions]
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This fixes the following small error in tfrc_calc_x_reverse_lookup.
1) The table is generated by the following equations:
lookup[index][0] = g((index+1) * 1000000/TFRC_CALC_X_ARRSIZE);
lookup[index][1] = g((index+1) * TFRC_CALC_X_SPLIT/TFRC_CALC_X_ARRSIZE);
where g(q) is 1E6 * f(q/1E6)
2) The reverse lookup assigns an entry in lookup[index][small]
3) This index needs to match the above, i.e.
* if small=0 then
p = (index + 1) * 1000000/TFRC_CALC_X_ARRSIZE
* if small=1 then
p = (index+1) * TFRC_CALC_X_SPLIT/TFRC_CALC_X_ARRSIZE
These are exactly the changes that the patch makes; previously the code did
not conform to the way the lookup table was generated (this difference resulted
in a mean error of about 1.12%).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This adds documentation for the TCP Reno throughput equation which is at
the heart of the TFRC sending rate / loss rate calculations.
It spells out precisely how the values were determined and what they mean.
The equations were derived through reverse engineering and found to be
fully accurate (verified using test programs).
This patch does not change any code.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This avoids a (harmless) warning message being printed at the DCCP server
(the receiver of a DCCP half connection).
Incoming packets are both directed to
* ccid_hc_rx_packet_recv() for the server half
* ccid_hc_tx_packet_recv() for the client half
The message gets printed since on a server the client half is currently not
sending data packets.
This is resolved for the moment by checking the DCCP-role first. In future
times (bidirectional DCCP connections), this test may have to be more
sophisticated.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
The main object of this patch is the following bug:
==> In ccid3_hc_tx_packet_recv, the parameters p and X_recv were updated
_after_ the send rate was calculated. This is clearly an error and is
resolved by re-ordering statements.
In addition,
* r_sample is converted from u32 to long to check whether the time difference
was negative (it would otherwise be converted to a large u32 value)
* protection against RTT=0 (this is possible) is provided in a further patch
* t_elapsed is also converted to long, to match the type of r_sample
* adds a a more debugging information regarding current send rates
* various trivial comment/documentation updates
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
This bug resulted in ccid3_hc_tx_send_packet returning negative
delay values, which in turn triggered silently dequeueing packets in
dccp_write_xmit. As a result, only a few out of the submitted packets made
it at all onto the network. Occasionally, when dccp_wait_for_ccid was
involved, this also triggered a bug warning since ccid3_hc_tx_send_packet
returned a negative value (which in reality was a negative delay value).
The cause for this bug lies in the comparison
if (delay >= hctx->ccid3hctx_delta)
return delay / 1000L;
The type of `delay' is `long', that of ccid3hctx_delta is `u32'. When comparing
negative long values against u32 values, the test returned `true' whenever delay
was smaller than 0 (meaning the packet was overdue to send).
The fix is by casting, subtracting, and then testing the difference with
regard to 0.
This has been tested and shown to work.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
The TFRC nofeedback timer normally expires after the maximum of 4
RTTs and twice the current send interval (RFC 3448, 4.3). On LANs
with a small RTT this can mean a high processing load and reduced
performance, since then the nofeedback timer is triggered very
frequently.
This patch provides a configuration option to set the bound for the
nofeedback timer, using as default 100 milliseconds.
By setting the configuration option to 0, strict RFC 3448 behaviour
can be enforced for the nofeedback timer.
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: Arnaldo Carvalho de Melo <acme@mandriva.com>
Misc Fixes:
- Prevent references to NULL node list element in reset routines.
- Add missing IOCB types to switch tables
- Reset the card on Port Error 5
- Fix infinite loop in LUN reset
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The driver now allows both wwpn and wwnn to be set.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
To avoid continually updating the driver for new subsystem ids
(as adapter modules are proliferating), remove this 2nd level decode.
Genericize the reported Adapter names to be consistent across
Emulex product line.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Add MSI (Message Signalled Interrupts) support
Actual use must be enabled via the new module parameter "lpfc_use_msi"
Defaults to no use
Many thanks to Frederic Temporelli who implemented the initial patch.
Signed-off-by: Frederic Temporelli <frederic.temporelli@ext.bull.net>
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Adjust LOG_FCP logging to be more meaningful.
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
It was not accounted for in the fast/slow rings.
Genericize the implementation and control it via sysfs
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Discovery Fixes:
- Prevent starting discovery of a node if discovery is in progress.
- Code improvement (reduction) for lpfc_findnode_did().
- Update discovery to send RFF to Fabric on link up
- Bypass unique WWN checks for fabric addresses
- Add ndlp to plogi list prior to issuing the plogi els command
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This is IBM Virtual SCSI target driver for tgt. The driver is based on
the original ibmvscsis driver:
http://lkml.org/lkml/2005/10/17/99
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Santiago Leon <santil@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
libsrp provides helper functions for SRP target drivers.
Some SRP target drivers would be out of drivers/scsi/ so we added an
entry for libsrp in drivers/scsi/Kconfig.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Santiago Leon <santil@us.ibm.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
