Jean Delvare [Fri, 24 Jun 2005 19:14:16 +0000 (21:14 +0200)]
[PATCH] I2C: New max6875 driver may corrupt EEPROMs
After a careful code analysis on the new max6875 driver
(drivers/i2c/chips/max6875.c), I have come to the conclusion that this
driver may cause EEPROM corruptions if used on random systems.
The EEPROM part of the MAX6875 chip is accessed using rather uncommon
I2C sequences. What is seen by the MAX6875 as reads can be seen by a
standard EEPROM (24C02) as writes. If you check the detection method
used by the driver, you'll find that the first SMBus command it will
send on the bus is i2c_smbus_write_byte_data(client, 0x80, 0x40). For
the MAX6875 it makes an internal pointer point to a specific offset of
the EEPROM waiting for a subsequent read command, so it's not an actual
data write operation, but for a standard EEPROM, this instead means
writing value 0x40 to offset 0x80. Blame Philips and Intel for the
obscure protocol.
Since the MAX6875 and the standard, common 24C02 EEPROMs share two I2C
addresses (0x50 and 0x52), loading the max6875 driver on a system with
standard EEPROMs at either address will trigger a write on these
EEPROMs, which will lead to their corruption if they happen not to be
write protected. This kind of EEPROMs can be found on memory modules
(SPD), ethernet adapters (MAC address), laptops (proprietary data) and
displays (EDID/DDC). Most of these are hopefully write-protected, but
not all of them.
For this reason, I would recommend that the max6875 driver be
neutralized, in a way that nobody can corrupt his/her EEPROMs by just
loading the driver. This means either deleting the driver completely, or
not listing any default address for it. I'd like this to be done before
2.6.13-rc1 is released.
Additionally, the max6875 driver lacks the 24RF08 corruption preventer
present in the eeprom driver, which means that loading this driver in a
system with such a chip would corrupt it as well.
Here is a proposed quick patch addressing the issue, although I wouldn't
mind a complete removal if it makes everyone feel safer. I think Ben
has plans to replace this driver by a much simplified one anyway.
Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Jean Delvare [Thu, 23 Jun 2005 20:18:08 +0000 (22:18 +0200)]
[PATCH] I2C: Strip trailing whitespace from strings
Here is a simple patch originally from Denis Vlasenko, which strips a
useless trailing whitespace from 8 strings in 4 i2c drivers. Please
apply, thanks.
This includes various small cleanups and fixes to the TPS 6501x driver that
came mostly from review feedback by Jean Delvare; thanks Jean! Also some
goofy whitespace gets fixed.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Denis Vlasenko [Wed, 22 Jun 2005 07:25:13 +0000 (10:25 +0300)]
[PATCH] I2C: Coding style cleanups to via686a
On Wednesday 22 June 2005 08:17, Greg KH wrote:
> [PATCH] I2C: Coding style cleanups to via686a
>
> The via686a hardware monitoring driver has infamous coding style at the
> moment. I'd like to clean up the mess before I start working on other
> changes to this driver. Is the following patch acceptable? No code
> change, only coding style (indentation, alignments, trailing white
> space, a few parentheses and a typo).
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Nice.
You missed some. This one is on top of your patch:
David S. Miller [Sun, 10 Jul 2005 23:55:48 +0000 (16:55 -0700)]
[SPARC64]: Pass regs and entry/exit boolean to syscall_trace()
Also fix a bug in 32-bit syscall tracing. We forgot to update
this code when we moved over to the convention that all 32-bit
syscall arguments are zero extended by default.
Signed-off-by: David S. Miller <davem@davemloft.net>
Stephen Rothwell [Sun, 10 Jul 2005 13:12:01 +0000 (23:12 +1000)]
[PATCH] remove asm-xtensa/ipc.h
Now that sys_ipc has been removed from xtensa, asm/ipc.h is no longer
needed for that architecture. Not tested, but obviously correct. This
file is included only from arch code and this patch also removes the only
inclusion.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ben Collins [Sun, 10 Jul 2005 00:01:23 +0000 (20:01 -0400)]
[PATCH] Sync up ieee-1394
Lots of this patch is trivial code cleanups (static vars were being
intialized to 0, etc).
There's also some fixes for ISO transmits (max buffer handling).
Aswell, we have a few fixes to disable IRM capabilites correctly. We've
also disabled, by default some generally unused EXPORT symbols for the
sake of cleanliness in the kernel. However, instead of removing them
completely, we felt it necessary to have a config option that allowed
them to be enabled for the many projects outside of the main kernel tree
that use our API for driver development.
The primary reason for this patch is to revert a MODE6->MODE10 RBC
conversion patch from the SCSI maintainers. The new conversions handled
directly in the scsi layer do not seem to work for SBP2. This patch
reverts to our old working code so that users can enjoy using Firewire
disks and dvd drives again.
We are working with the SCSI maintainers to resolve this issue outside
of the main kernel tree. We'll merge the patch once the SCSI layer's
handling of the MODE10 conversion is working for us.
Tony Lindgren [Sun, 10 Jul 2005 18:58:08 +0000 (19:58 +0100)]
[PATCH] ARM: 2798/1: OMAP update 2/11: Change ARM Kconfig to support omap1 and omap2
Patch from Tony Lindgren
This patch by Paul Mundt and other OMAP developers modifies
ARM specific Kconfig to allow sharing code between OMAP1 and
OMAP2 architectures.
In order to share code between OMAP1 and OMAP2, all OMAP1
specific code is moved into mach-omap1 directory in the
following patch. A new mach-omap2 directory will be added
later on.
Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[PATCH] ARM: 2796/1: Fix ARMv5[TEJ] check in MMU initalization
Patch from Deepak Saxena
The code in mm-armv.c checks for the condition (cpu_architecture()<= ARMv5)
in a few places but should be checking for ARMv5TEJ as the MMU is shared
across all v5 variations.
Signed-off-by: Deepak Saxena <dsaxena@plexity.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
David L Stevens [Sat, 9 Jul 2005 00:48:38 +0000 (17:48 -0700)]
[IPV4]: fix IPv4 leave-group group matching
This patch fixes the multicast group matching for
IP_DROP_MEMBERSHIP, similar to the IP_ADD_MEMBERSHIP fix in a prior
patch. Groups are identifiedby <group address,interface> and including
the interface address in the match will fail if a leave-group is done
by address when the join was done by index, or if different addresses
on the same interface are used in the join and leave.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David L Stevens [Sat, 9 Jul 2005 00:39:23 +0000 (17:39 -0700)]
[IPV4]: multicast API "join" issues
1) Changes IP_ADD_SOURCE_MEMBERSHIP and MCAST_JOIN_SOURCE_GROUP to ignore
EADDRINUSE errors on a "courtesy join" -- prior membership or not
is ok for these.
2) Adds "leave group" equivalence of (INCLUDE, empty) filters in the
delta-based API. Without this, mixing delta-based API calls that
end in an (INCLUDE, empty) filter would not allow a subsequent
regular IP_ADD_MEMBERSHIP. It also frees socket buffer memory that
isn't needed for both the multicast group record and source filter.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
David L Stevens [Sat, 9 Jul 2005 00:38:07 +0000 (17:38 -0700)]
[IPV4]: multicast API "join" issues
This patch corrects a few problems with the IP_ADD_MEMBERSHIP
socket option:
1) The existing code makes an attempt at reference counting joins when
using the ip_mreqn/imr_ifindex interface. Joining the same group
on the same socket is an error, whatever the API. This leads to
unexpected results when mixing ip_mreqn by index with ip_mreqn by
address, ip_mreq, or other API's. For example, ip_mreq followed by
ip_mreqn of the same group will "work" while the same two reversed
will not.
Fixed to always return EADDRINUSE on a duplicate join and
removed the (now unused) reference count in ip_mc_socklist.
2) The group-search list in ip_mc_join_group() is comparing a full
ip_mreqn structure and all of it must match for it to find the
group. This doesn't correctly match a group that was joined with
ip_mreq or ip_mreqn with an address (with or without an index). It
also doesn't match groups that are joined by different addresses on
the same interface. All of these are the same multicast group,
which is identified by group address and interface index.
Fixed the check to correctly match groups so we don't get
duplicate group entries on the ip_mc_socklist.
3) The old code allocates a multicast address before searching for
duplicates requiring it to free in various error cases. This
patch moves the allocate until after the search and
igmp_max_memberships check, so never a need to allocate, then free
an entry.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Victor Fusco [Fri, 8 Jul 2005 21:57:47 +0000 (14:57 -0700)]
[NET]: Fix sparse warnings
From: Victor Fusco <victor@cetuc.puc-rio.br>
Fix the sparse warning "implicit cast to nocast type"
Signed-off-by: Victor Fusco <victor@cetuc.puc-rio.br> Signed-off-by: Domen Puncer <domen@coderock.org> Signed-off-by: David S. Miller <davem@davemloft.net>
David S. Miller [Fri, 8 Jul 2005 21:57:23 +0000 (14:57 -0700)]
[NET]: Transform skb_queue_len() binary tests into skb_queue_empty()
This is part of the grand scheme to eliminate the qlen
member of skb_queue_head, and subsequently remove the
'list' member of sk_buff.
Most users of skb_queue_len() want to know if the queue is
empty or not, and that's trivially done with skb_queue_empty()
which doesn't use the skb_queue_head->qlen member and instead
uses the queue list emptyness as the test.
Signed-off-by: David S. Miller <davem@davemloft.net>
[PATCH] device-mapper: dm-raid1: Limit bios to size of mirror region
Set the target's split_io field when building a dm-mirror device so
incoming bios won't span the mirror's internal regions. Without this,
regions can be accessed while not holding correct locks and data corruption
is possible.
Reported-By: "Zhao Qian" <zhaoqian@aaastor.com>
From: Kevin Corry <kevcorry@us.ibm.com> Signed-Off-By: Alasdair G Kergon <agk@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch is for supporting Epson s1d13xxx framebuffer device for m32r. #
Sorry, a little bigger.
The Epson s1d13806 is already supported by 2.6.12 kernel, and its driver is
placed as drivers/video/s1d13xxxfb.c.
For the m32r, a header file include/asm-m32r/s1d13806.h was prepared for
several m32r target platforms. It was originally generated by an Epson
tool S1D13806CFG.EXE, and modified manually for the m32r platforms.
After discussion at the recent NFSv4 bake-a-thon, I realized that my
assumption that NFS4_FH_PERSISTENT required filehandles to persist was a
misreading of the spec. This also fixes an interoperability problem with the
Solaris client.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We shouldn't be allowing, e.g., write locks on files not open for read. To
enforce this, we add a pointer from the lock stateid back to the open stateid
it came from, so that the check will continue to be correct even after the
open is upgraded or downgraded.
Signed-off-by: Andy Adamson <andros@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
As long as we're here, do some miscellaneous cleanup.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The handling of close_lru in preprocess_stateid_op was a source of some
confusion here recently. Try to make the logic a little clearer, by renaming
find_openstateowner_id to make its purpose clearer and untangling some
unnecessarily complicated goto's.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] nfsd4: renew lease on seqid modifying operations
nfs4_preprocess_seqid_op is called by NFSv4 operations that imply an implicit
renewal of the client lease.
Signed-off-by: Andy Adamson <andros@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] nfsd4: return better error on io incompatible with open mode
from RFC 3530:
"Share reservations are established by OPEN operations and by their
nature are mandatory in that when the OPEN denies READ or WRITE
operations, that denial results in such operations being rejected
with error NFS4ERR_LOCKED."
(Note that share_denied is really only a legal error for OPEN.)
Signed-off-by: Andy Adamson <andros@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An OPEN from the same client/open stateowner requires a stateid update because
of the share/deny access update.
Signed-off-by: Andy Adamson <andros@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We're insisting that the lock sequence id field passed in the
open_to_lockowner struct always be zero. This is probably thanks to the
sentence in rfc3530: "The first request issued for any given lock_owner is
issued with a sequence number of zero."
But there doesn't seem to be any problem with allowing initial sequence
numbers other than zero. And currently this is causing lock reclaims from the
Linux client to fail.
In the spirit of "be liberal in what you accept, conservative in what you
send", we'll relax the check (and patch the Linux client as well).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Add some comments on the use of so_seqid, in an attempt to avoid some of the
confusion outlined in the previous patch....
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The sequence number we store in the sequence id is the last one we received
from the client. So on the next operation we'll check that the client gives
us the next higher number.
We increment sequence id's at the last moment, in encode, so that we're sure
of knowing the right error return. (The decision to increment the sequence id
depends on the exact error returned.)
However on the *first* use of a sequence number, if we set the sequence number
to the one received from the client and then let the increment happen on
encode, we'll be left with a sequence number one to high.
For that reason, ENCODE_SEQID_OP_TAIL only increments the sequence id on
*confirmed* stateowners.
This creates a problem for open reclaims, which are confirmed on first use.
Therefore the open reclaim code, as a special exception, *decrements* the
sequence id, cancelling out the undesired increment on encode. But this
prevents the sequence id from ever being incremented in the case where
multiple reclaims are sent with the same openowner. Yuch!
We could add another exception to the open reclaim code, decrementing the
sequence id only if this is the first use of the open owner.
But it's simpler by far to modify the meaning of the op_seqid field: instead
of representing the previous value sent by the client, we take op_seqid, after
encoding, to represent the *next* sequence id that we expect from the client.
This eliminates the need for special-case handling of the first use of a
stateowner.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Yeah, it's trivial, but this drives me up the wall....
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
A misreading of the spec lead us to convert all errors on open and lock
reclaims to RECLAIM_BAD. This causes problems--for example, a reboot within
the grace period could lead to reclaims with stale stateid's, and we'd like to
return STALE errors in those cases.
What rfc3530 actually says about RECLAIM_BAD: "The reclaim provided by the
client does not match any of the server's state consistency checks and is
bad." I'm assuming that "state consistency checks" refers to checks for
consistency with the state recorded to stable storage, and that the error
should be reserved for that case.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] nfsd4: ERR_GRACE should bump seqid on lock
A GRACE or NOGRACE response to a lock request should also bump the sequence
id. So we delay the handling of grace period errors till after we've found
the relevant owner.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] nfsd4: ERR_GRACE should bump seqid on open
The GRACE and NOGRACE errors should bump the sequence id on open. So we delay
the handling of these errors until nfsd4_process_open2, at which point we've
set the open owner, so the encode routine will be able to bump the sequence
id.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We oops in list_for_each_entry(), because release_stateowner frees something
on the list we're traversing.
Signed-off-by: Andy Adamson <andros@citi.umich.edu> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] nfsd4: prevent multiple unlinks of recovery directories
Make sure we don't try to delete client recovery directories multiple times;
fixes some spurious error messages.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We need to fsync the recovery directory after writing to it, but we weren't
doing this correctly. (For example, we weren't taking the i_sem when calling
->fsync().)
Just reuse the existing nfsd fsync code instead.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
We need to remove the recovery directory here too. (This chunk just got lost
somehow in the process of commuting the reboot recovery patches past the other
patches.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Russell King [Fri, 8 Jul 2005 00:59:07 +0000 (17:59 -0700)]
[PATCH] yenta: no CardBus if IRQ fails
If probing for the correct interrupt fails on yenta bridges, the driver falls
back to polling for interrupt actions. However, CardBus cards cannot be used
then.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Pavel Roskin [Fri, 8 Jul 2005 00:59:04 +0000 (17:59 -0700)]
[PATCH] pcmcia: remove client services version (fix)
One correction is needed. Changes are not needed for
drivers/scsi/pcmcia/nsp_cs.c because it uses versioning in the
compatibility part, which is never used in 2.6 kernels. The only right
thing we could to that compatibility code would be to remove it throughout
the file, but that would be a separate patch.
Pavel Roskin [Fri, 8 Jul 2005 00:59:03 +0000 (17:59 -0700)]
[PATCH] pcmcia: remove client services version
The Linux PCMCIA code has some data that was apparently used (or meant to be
used) to ensure that only proper client drivers are loaded. This is now
ensured (to a certain degree) by the fact that the most client drivers are
part of the kernel. Also, the version information has not been updated
despite major changes in PCMCIA API. This has made it meaningless.
This patch removes servinfo_t and pcmcia_get_card_services_info. They are not
used in any userspace utilities such as pcmcia-cs and pcmciautils.
drivers/pcmcia/pcmcia_ioctl.c is adjusted accordingly.
CS_RELEASE and CS_RELEASE_CODE are removed. include/pcmcia/version.h is empty
now. It will be removed later, but for now it's left in the tree to avoid
touching all PCMCIA clients.
The only driver that needs to be changed is drivers/scsi/pcmcia/nsp_cs.c,
which uses CS_RELEASE_CODE.
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Move the "event handler" to struct pcmcia_driver -- the unified event handler
will disappear really soon, but switching it to struct pcmcia_driver in the
meantime allows for better "step-by-step" patches.
Schedule removal of the PCMCIA ioctl (and thus kernel support for the
pcmcia-cs userspace package) for November 2005.
A big "thank you" to Dave Hinds for his great work on supporting PCMCIA in
Linux. Things are just done differently by now, so the ongoing work to make
PCMCIA behave like any other hotpluggable bus should continue.
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=f354942cb301fed273f423fb5c4f57bde3efc5b2
converted the check_region() calls in drivers/pcmcia/i82365.c into
request_regions. Unfortunately this seems to have broken things.
isa_probe() used to call check_region() and then call add_pcic() which would
request_region().
Now isa_probe() calls request_region() and then calls add_pcic() which calls
request_region() again, this fails and add_pcic() returns immediately without
doing all the setup etc.
On the face of it the patch below fixes the problem, by not doing the second
request region in add_pcic(). I think this is preferable to remove the call
in isa_probe() since identify() touches the I/O regions and is called before
add_pcic().
However I haven't fully grokked the meaning of the code which follows the
request_region() in isa_probe(), so I'm not sure that the handling WRT
multiple sockets and multiple bridge chips is correct. In particular I'm not
convinced that the regions for subsequent sockets and/or bridges will be
requested at all. I suspect a more thorough reworking by someone who
understands what is going on there might be in order.
I should mention that I'm actually messing about with this on an ARM platform
with wacky memory and i/o mapping offsets etc, it doesn't quite work yet for
other reasons which preclude full testing etc, but I think the problem above
is still present for more normal x86 stuff.
Signed-off-by: Ian Campbell <icampbell@arcom.com> Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Krufky [Fri, 8 Jul 2005 00:58:42 +0000 (17:58 -0700)]
[PATCH] v4l: add DVB support for DViCO FusionHDTV3 Gold-T
- Correct sync byte for MPEG-2 transport stream packets.
- Add lgdt3302 as dependency of cx88-dvb in Kconfig.
- Add dvb support in v4l for DViCO FusionHDTV3 Gold-T using lgdt3302 frontend.
This adds support for a different board from the previous (Gold-Q) patch.
Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Krufky [Fri, 8 Jul 2005 00:58:38 +0000 (17:58 -0700)]
[PATCH] v4l: cx88 hue offset fix
Changed hue offset to 128 to correct behavior in cx88 cards. Previously,
setting 0% or 100% hue was required to avoid blue/green people on screen.
Now, 50% Hue means no offset, just like bt878 stuff.
Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
- Add support for ADS Tech Instant TV DVB-T PCI.
- Remove obsoleted config options.
- Fix DViCO Board names
- Remove CABLE type setting from DViCO FusionHDTV3 Gold-T.
- Fix compilation with gcc4.0.
- V4L2_TUNER_CAP_LOW implemented according with V4L2 API for Radio.
- radio range is now defined on tuner-core.c. Cleaning up.
- Fix a bug on frequency report for cx88 based cards.
- Added support for changing radio mode stereo/mono.
- Add remove for MSI TV@nywhere.
almost completely remade the text file with the following focuses:
useful infos for beginners: how to load modules manually and
automatically developers infos are reduced to a minimum as module loading
works automatic in kernel >= 2.6.12 by loading modules bttv and dvb-bt8xx
I completely erased the out of date TwinHan part dealing with additional
parameters, debug parameters, and overriding autodetection Further up to
date information about TwinHan + clones can be found in
/Documentation/dvb/ci.txt
Add support and rewrote some parts with the help of vendor information
(Thanks to Steve Chang from WideView, Inc.):
o added support for the WT-220U (Pensize DVB-T receiver)
o corrected byte order for unc,ber and the pid filter
o corrected number of pids that can be fetched at the same time.
o added some comments in Kconfig-file
o added USB IDs for the WT-220U
Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix tuning failure for 200103A, 200103A failed to tune to low band due to
wrong tone setting on the 200103A.
Signed-off-by: Steffen Motzer <motzersn@tlink.de> Signed-off-by: Manu Abraham <manu@kromtek.com> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
[PATCH] dvb: usb/pci: correct syntax of driver name fields
Change the name-field of the pci_driver and usb_driver structs to the name of
the module after compilation. It seems that this field is used in some places
where special characters are not allowed. Thanks to Alan Halverson for
finding this problem.
Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Mac Michaels [Fri, 8 Jul 2005 00:58:29 +0000 (17:58 -0700)]
[PATCH] dvb: frontend: add driver for LGDT3302
Add support for LGDT3302 (ATSC VSB/QAM) used in DViCO FusionHDTV3 Gold.
Signed-off-by: Mac Michaels <wmichaels1@earthlink.net> Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Paxton [Fri, 8 Jul 2005 00:58:24 +0000 (17:58 -0700)]
[PATCH] dvb: usb: vp7045 IR map fix
Correct two keys of the vp7045 remote control key mapping.
Signed-off-by: Michael Paxton <packo@tpg.com.au> Signed-off-by: Patrick Boettcher <pb@linuxtv.org> Signed-off-by: Johannes Stezenbach <js@linuxtv.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
projects / karo-tx-linux.git / log