Mark Haverkamp [Wed, 27 Apr 2005 13:05:51 +0000 (06:05 -0700)]
[SCSI] aacraid: remove sparse warnings
This patch addresses the sparse -Wbitwise warnings that Christoph wanted
me to eliminate. This mostly consisted of making data structure
elements of hardware associated structures the __le* equivalent.
Although there were a couple places where there was mixing of cpu and le
variable math. These changes have been tested on both an x86 and ppc
machine running bonnie++. The usage of the LE32_ALL_ONES macro has been
eliminated.
Signed-off-by: Mark Haverkamp <markh@osdl.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
drivers/scsi/dpt_i2o.c: In function ‘adpt_isr’:
drivers/scsi/dpt_i2o.c:2030: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2031: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2042: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2043: warning: passing argument 2 of ‘writel’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2046: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2048: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2055: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2062: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2069: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c: In function ‘adpt_i2o_to_scsi’: drivers/scsi/dpt_i2o.c:2239: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2243: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2248: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
drivers/scsi/dpt_i2o.c:2259: warning: passing argument 1 of ‘readl’ makes pointer from integer without a cast
It define variables which are only used with a type of 'void __iomem *'
with this type instead of the incorrect 'unsigned long' type.
It also remove pointless casts.
Signed-off-by: Benoit Boissinot <benoit.boissinot@ens-lyon.org> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
This patch contains cleanups including the following:
- remove #ifdef'ed code for other OS's
- remove other unused code
- make needlessly global code static
Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] make scsi_queue_insert() use blk_requeue_request()
scsi_queue_insert() used to use blk_insert_request() for requeueing
requests. This depends on the unobvious behavior of
blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when
requeueing. This patch makes scsi_queue_insert() use
blk_requeue_request(). As REQ_SPECIAL means special requests and
REQ_SOFTBARRIER is automatically handled by blk layer now, no flag
needs to be set.
Note that scsi_queue_insert() now calls scsi_run_queue() itself, and
the prototype of the function is added right above
scsi_queue_insert(). This is temporary, as later requeue path
consolidation patchset removes scsi_queue_insert(). By adding
temporary prototype, we can do away with unnecessarily moving
functions.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] make scsi_requeue_request() use blk_requeue_request()
scsi_requeue_request() used to use blk_insert_request() for requeueing
requests. This depends on the unobvious behavior of
blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when
requeueing. This patch makes scsi_queue_insert() use
blk_requeue_request(). As REQ_SPECIAL means special requests and
REQ_SOFTBARRIER is automatically handled by blk layer now, no flag
needs to be set.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] remove requeue feature from blk_insert_request()
blk_insert_request() has a unobivous feature of requeuing a
request setting REQ_SPECIAL|REQ_SOFTBARRIER. SCSI midlayer
was the only user and as previous patches removed the usage,
remove the feature from blk_insert_request(). Only special
requests should be queued with blk_insert_request(). All
requeueing should go through blk_requeue_request().
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
scsi_init_io() used to set REQ_SPECIAL when it fails sg
allocation before requeueing the request by returning
BLKPREP_DEFER. REQ_SPECIAL is being updated to mean special
requests. So, remove REQ_SPECIAL setting.
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] make blk layer set REQ_SOFTBARRIER on defer and requeue
This is the reworked version of the patch. It sets REQ_SOFTBARRIER
in two places - in elv_next_request() on BLKPREP_DEFER and in
blk_requeue_request().
Signed-off-by: Tejun Heo <htejun@gmail.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
The fusion Kconfig forgets to set CONFIG_FUSION, which is required to
get the upper makefile to descend into the fusion directory. Add this
back as a variable and make the two upper level modules select it.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
(1) mptfc.c: This driver is having module_init, module_exit, and probe.
(2) mptfc.c: Registering for Fibre Channel pci ids are done from this
module.
(3) mptfc.c: Convert MODULE_PARM to module_param
Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
(1) mptspi.c: This driver is having module_init, module_exit, and probe.
(2) mptspi.c: Registering for SCSI pci ids are done from this module.
(3) mptspi.c: Convert MODULE_PARM to module_param
Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
(1) mptscsih.c: Remove credits, -sralston references , update copyright
(2) mptscsih.c: split driver support
(3) mptscsih.c: module_init, module_exit, and probe routines moved to new
stub drivers, mptfc and mptspi
(4) mptscsih.c: some global parameters are moved to MPT_SCSI_HOST
(5) mptscsih.c: removed scsi_device_online check.
Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
[SCSI] mptfusion: Kconfig Adding new bus type drivers for fusion drivers.
(1) Kconfig - added new mptspi and mptfc scsi lld drivers
(2) Kconfig - increased MAX_SGE from 40 to 128
(2) Makefile - compilation support for split drivers
(3) Makefile - cleaned up debug defines; e.g. removed obsolete, added others
Signed-off-by: Eric Moore <Eric.Moore@lsil.com> Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Both drivers are marked broken and haven't compiled since very early
2.5.x. And they're for IDE hardware so they shouldn't have been
written to the SCSI layer at all.
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Thomas Graf [Wed, 20 Apr 2005 05:35:07 +0000 (22:35 -0700)]
[RTNETLINK]: Protocol family wildcard dumping for routing rules
Be kind to userspace and don't force them to hardcode protocol
families just to have it changed again once we support routing
rules for more than one protocol family.
Signed-off-by: Thomas Graf <tgraf@suug.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
Herbert Xu [Wed, 20 Apr 2005 05:32:22 +0000 (22:32 -0700)]
[IPV6]: Replace bogus instances of inet->recverr
While looking at this problem I noticed that IPv6 was sometimes
looking at inet->recverr which is bogus. Here is a patch to
correct that and use np->recverr.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net>
ARM26 define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors when
they are mapped low), and use that definition in place of locally defined
MIN_MAP_ADDR. Previously, ARM26 permitted user mappings at 0 if the machine
vectors were mapped high; but that's inconsistent with ARM, and
FIRST_USER_ADDRESS would then have to be determined at runtime. Let's fix it
at PAGE_SIZE throughout the architecture.
ARM define FIRST_USER_ADDRESS as PAGE_SIZE (beyond the machine vectors when
they are mapped low), and use that definition in place of locally defined
MIN_MAP_ADDR.
Remove use of FIRST_USER_PGD_NR from sys_mincore: it's inconsistent (no other
syscall refers to it), unnecessary (sys_mincore loops over vmas further down)
and incorrect (misses user addresses in ARM's first pgd).
[PATCH] freepgt: free_pgtables from FIRST_USER_ADDRESS
The patches to free_pgtables by vma left problems on any architectures which
leave some user address page table entries unencapsulated by vma. Andi has
fixed the 32-bit vDSO on x86_64 to use a vma. Now fix arm (and arm26), whose
first PAGE_SIZE is reserved (perhaps) for machine vectors.
Our calls to free_pgtables must not touch that area, and exit_mmap's
BUG_ON(nr_ptes) must allow that arm's get_pgd_slow may (or may not) have
allocated an extra page table, which its free_pgd_slow would free later.
FIRST_USER_PGD_NR has misled me and others: until all the arches define
FIRST_USER_ADDRESS instead, a hack in mmap.c to derive one from t'other. This
patch fixes the bugs, the remaining patches just clean it up.
Once we're strict about clearing away page tables, hugetlb_prefault can assume
there are no page tables left within its range. Since the other arches
continue if !pte_none here, let i386 do the same.
ia64 and sparc64 hurriedly had to introduce their own variants of
pgd_addr_end, to leapfrog over the holes in their virtual address spaces which
the final clear_page_range suddenly presented when converted from pgd_index to
pgd_addr_end. But now that free_pgtables respects the vma list, those holes
are never presented, and the arch variants can go.
ia64 and ppc64 had hugetlb_free_pgtables functions which were no longer being
called, and it wasn't obvious what to do about them.
The ppc64 case turns out to be easy: the associated tables are noted elsewhere
and freed later, safe to either skip its hugetlb areas or go through the
motions of freeing nothing. Since ia64 does need a special case, restore to
ppc64 the special case of skipping them.
The ia64 hugetlb case has been broken since pgd_addr_end went in, though it
probably appeared to work okay if you just had one such area; in fact it's
been broken much longer if you consider a long munmap spanning from another
region into the hugetlb region.
In the ia64 hugetlb region, more virtual address bits are available than in
the other regions, yet the page tables are structured the same way: the page
at the bottom is larger. Here we need to scale down each addr before passing
it to the standard free_pgd_range. Was about to write a hugely_scaled_down
macro, but found htlbpage_to_page already exists for just this purpose. Fixed
off-by-one in ia64 is_hugepage_only_range.
Uninline free_pgd_range to make it available to ia64. Make sure the
vma-gathering loop in free_pgtables cannot join a hugepage_only_range to any
other (safe to join huges? probably but don't bother).
There's only one usage of MM_VM_SIZE(mm) left, and it's a troublesome macro
because mm doesn't contain the (32-bit emulation?) info needed. But it too is
only needed because we ignore the end from the vma list.
We could make flush_pgtables return that end, or unmap_vmas. Choose the
latter, since it's a natural fit with unmap_mapping_range_vma needing to know
its restart addr. This does make more than minimal change, but if unmap_vmas
had returned the end before, this is how we'd have done it, rather than
storing the break_addr in zap_details.
unmap_vmas used to return count of vmas scanned, but that's just debug which
hasn't been useful in a while; and if we want the map_count 0 on exit check
back, it can easily come from the final remove_vm_struct loop.
Recent woes with some arches needing their own pgd_addr_end macro; and 4-level
clear_page_range regression since 2.6.10's clear_page_tables; and its
long-standing well-known inefficiency in searching throughout the higher-level
page tables for those few entries to clear and free: all can be blamed on
ignoring the list of vmas when we free page tables.
Replace exit_mmap's clear_page_range of the total user address space by
free_pgtables operating on the mm's vma list; unmap_region use it in the same
way, giving floor and ceiling beyond which it may not free tables. This
brings lmbench fork/exec/sh numbers back to 2.6.10 (unless preempt is enabled,
in which case latency fixes spoil unmap_vmas throughput).
Beware: the do_mmap_pgoff driver failure case must now use unmap_region
instead of zap_page_range, since a page table might have been allocated, and
can only be freed while it is touched by some vma.
Move free_pgtables from mmap.c to memory.c, where its lower levels are adapted
from the clear_page_range levels. (Most of free_pgtables' old code was
actually for a non-existent case, prev not properly set up, dating from before
hch gave us split_vma.) Pass mmu_gather** in the public interfaces, since we
might want to add latency lockdrops later; but no attempt to do so yet, going
by vma should itself reduce latency.
But what if is_hugepage_only_range? Those ia64 and ppc64 cases need careful
examination: put that off until a later patch of the series.
What of x86_64's 32bit vdso page __map_syscall32 maps outside any vma?
And the range to sparc64's flush_tlb_pgtables? It's less clear to me now that
we need to do more than is done here - every PMD_SIZE ever occupied will be
flushed, do we really have to flush every PGDIR_SIZE ever partially occupied?
A shame to complicate it unnecessarily.
Special thanks to David Miller for time spent repairing my ceilings.
I can't use list.h, since sk_buff doesn't have a list_head but instead
has two struct sk_buff pointers, and I want to avoid any extra memory
allocation.
send outgoing packets in order
Signed-off-by: Ed L. Cashin <ecashin@coraid.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current <linux/debugfs.h> include file is a little fragile in that
it is not self-contained and hence may cause compile warnings or
errors depending on the files included before it, the kernel config
and the architecture. This patch makes things a little more robust by:
- including <linux/types.h> to get definitions of u32, mode_t, and so on.
- forward declaring struct file_operations.
- including <linux/err.h> when CONFIG_DEBUG_FS is not set
The last change is particularly useful, as a kernel developer is
likely to build with debugfs always enabled and never see the build
breakage cased if debugfs is disabled.
Signed-off-by: Roland Dreier <roland@topspin.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Robert Schwebel [Tue, 19 Apr 2005 04:57:32 +0000 (21:57 -0700)]
[PATCH] export platform_add_devices
platform_add_devices can be used from within modules, so it should be
exported. This can for example happen if you have hotpluggable firmware in
an FPGA on a system on chip processor; in our case the FPGA is probed for
devices and the FPGA base code registers the devices it has found with the
kernel.
(akpm: I think this is reasonable from a licensing POV: it's unlikely that
anyone would be interested in merging such specialised modules into mainline,
and it's a GPL export).
Signed-off-by: Robert Schwebel <r.schwebel@pengutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[PATCH] add TIMEOUT to firmware_class hotplug event
On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> The current implementation of the firmware class breaks a fundamental
> assumption in udevd: that the physical device can be initialised fully
> prior to executing the next event for that device.
Here we add a TIMEOUT value to the hotplug environment of the firmware
requesting event. I will adapt udevd not to wait for anything else, if
it finds a TIMEOUT key.
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Tue, 19 Apr 2005 04:16:59 +0000 (21:16 -0700)]
[PATCH] I2C: Fix incorrect sysfs file permissions in it87 and via686a drivers
The it87 and via686a hardware monitoring drivers each create a sysfs
file named "alarms" in R/W mode, while they should really create it in
read-only mode. Since we don't provide a store function for these files,
write attempts to these files will do something undefined (I guess) and
bad (I am sure). My own try resulted in a locked terminal (where I
attempted the write) and a 100% CPU load until next reboot.
As a side note, wouldn't it make sense to check, when creating sysfs
files, that readable files have a non-NULL show method, and writable
files have a non-NULL store method? I know drivers are not supposed to
do stupid things, but there is already a BUG_ON for several conditions
in sysfs_create_file, so maybe we could add two more?
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 19 Apr 2005 00:39:30 +0000 (17:39 -0700)]
[PATCH] USB: USB API documentation modification
In response to complaints about excessive latency in the uhci-hcd driver
I'm planning to convert it to a top-half/bottom-half design. It turns out
that to do this, the USB API has to be modified slightly since the driver
will not be able to meet one of the guarantees in the current API. This
patch changes some kerneldoc, specifying the weaker guarantee.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
David Brownell [Tue, 19 Apr 2005 00:39:30 +0000 (17:39 -0700)]
[PATCH] USB: OHCI on Compaq Aramada 7400
This adds a quirk to the OHCI driver that lets it work with an old
Compaq implementation. It also removes some needless strings from
the non-debug version of the driver.
Signed-off-by: Chris Clayton <chris_clayton@f1internet.com> Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
projects / linux-beck.git / log