Move I2C driver model init earlier in the boot sequence.
This avoids oopsing in statically linked systems when some
subsystems register I2C drivers in subsys_initcall() code,
but those subsystems are linked (and initialized) before I2C.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The two Tyan SMBus mux drivers (i2c-amd756-s4882 and i2c-nforce2-s4985)
are only useful on specific x86 motherboards, so there is no point in
letting them be built on other architectures.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Guard I2C against oopsing because of init sequence problems, by
verifying that i2c_init() has been called before calling any
routines that rely on that initialization. This specific test
just requires that bus_register(&i2c_bus_type) was called.
Examples of this kind of oopsing come from subystems and drivers
which register I2C drivers in their subsys_initcall code but
which are statically linked before I2C by drivers/Makefile.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
I wrote this explanation to answer a question on the i2c mailing list,
and thought it would be good to have in the kernel documentation.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
* Clarify some points.
* Point developers to i2c-tools instead of lm_sensors.
* Fix coding style in code examples.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The i2c-parport-light driver isn't a real platform driver, so it
should not instantiate platform devices with resources. The resource
management system can't cope with colliding resources, and we are
likely to create such a colliding resource.
So, better just try to grab the I/O ports we need right at module
initialization time, and bail out if we can't. It has the added
benefit that the module will no longer load if it isn't going to work,
which is definitely more user-friendly.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The new-style dme1737 driver implements the optional detect() callback
to cover the use cases of the legacy driver. I don't actually expect
any new-style device for that driver, but as the old i2c API is going
away soon, we have to switch to the new one.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Juerg Haefliger <juergh@gmail.com>
The dme1737 driver support both LPC (ISA) and SMBus devices. At the
moment it's rather i2c-centric, and LPC variants use a fake i2c_client
for some operations.
In a near future, i2c_client will be allocated by i2c-core rather than
by the device drivers, so non-i2c drivers will not have one. As a
preparation step, change the driver code to no longer assume that
an i2c_client structure is always available. No functional change.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Juerg Haefliger <juergh@gmail.com>
All the tps6501{0,1,2,3,4} chips have a signal for hooking up with
a vibrator (for non-auditory cell phone "ring") ... expose that as
one more (output-only) GPIO.
[ dbrownell@users.sourceforge.net: comments; list tps65014 too ]
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Thanks to new datasheets published on http://linux.via.com.tw we can now add
support for VX800/VX820 chipsets.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
This adds support for the SMBus adapter found in the various FPGAs on
the Renesas Highlander platforms. Particularly the R0P7780LC0011RL and
R0P7785LC0011RL FPGAs.
Functionality is fairly restricted, in that only byte and block data
transfers are supported. Normal/fast mode and IRQ/polling are also
supported. Primarily used for various RTCs and thermal sensors.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Grabbing ISA bus resources without anything or anyone telling us we
should can break boot on randconfig/allyesconfig builds by keeping
resources that are in fact owned by different hardware busy and does
as reported by Ingo Molnar.
Generally it's also dangerous to just poke at random I/O ports and
especially those in the range where other old easily confused ISA
hardware might live.
For this specialized I2C bus driver, insist that the user specifies
the resources before grabbing them.
The^WA user of this driver is a one time
echo "options i2c-pca-isa base=0x330 irq=10" >> /etc/modprobe.conf
away from the old behaviour.
Signed-off-by: Rene Herman <rene.herman@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Based on David Brownell's patch for tps65010 and previous work by
Felipe Balbi, this patch finishes converting isp1301_omap to a
new-style i2c driver.
There's definitely room for further drivers cleanups, but these are
out of the scope of this patch.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Based on David Brownell's patch for tps65010, this patch
starts converting isp1301_omap.c to new-style i2c driver.
Signed-off-by: Felipe Balbi <me@felipebalbi.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Tony Lindgren <tony@atomide.com>
This ASIC does support all page sizes. For 4k and 8k page size the TX
control block needs an external scatter gather list. For page sizes
larger than 8k the max frags is satisfied by the original TX control
block.
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Clean up the various different email addresses of mine listed in the code
to a single current and valid address. As Dave says his network merges
for 2.6.28 are now done this seems a good point to send them in where
they won't risk disrupting real changes.
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
git commit 45cec1bac0
"dsa: Need to select PHYLIB." causes this build bug on s390:
drivers/built-in.o: In function `phy_stop_interrupts':
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:631: undefined reference to `free_irq'
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:646: undefined reference to `enable_irq'
drivers/built-in.o: In function `phy_start_interrupts':
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:601: undefined reference to `request_irq'
drivers/built-in.o: In function `phy_interrupt':
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:528: undefined reference to `disable_irq_nosync'
drivers/built-in.o: In function `phy_change':
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:674: undefined reference to `enable_irq'
/home/heicarst/linux-2.6/drivers/net/phy/phy.c:692: undefined reference to `disable_irq'
PHYLIB has alread a depend on !S390, however select PHYLIB at DSA overrides
that unfortunately. So add a depend on !S390 to DSA as well.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
LD net/ipv6/ipv6.o
WARNING: net/ipv6/ipv6.o(.text+0xd8): Section mismatch in reference from the function inet6_net_init() to the function .init.text:ipv6_init_mibs()
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I don't think the enic driver has anything to do with Mark Everett
(http://en.wikipedia.org/wiki/A_Man_Called_E). Fix the Kconfig
description.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The de2104x returns sometimes a wrong MAC address. The wrong one is
like the original one, but it comes with an one byte shift. I found
this bug on an older alpha ev5 cpu. More details are available in Gentoo
bugreport #240718.
It seems the hardware is sometimes a little bit too slow for an
immediate access. This patch solves the problem by introducing a small
udelay.
Signed-off-by: Martin Langer <martin-langer@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch fixes the following build error caused by
commit ed94493fb3
(mv643xx_eth: convert to phylib):
<-- snip -->
...
Building modules, stage 2.
MODPOST 1280 modules
ERROR: "genphy_restart_aneg" [drivers/net/mv643xx_eth.ko] undefined!
...
make[2]: *** [__modpost] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add a field to the driver versioning info.
Update version to 1.1.0.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix kernel-doc warning, missing description:
Warning(lin2627-g3-kdocfixes//drivers/net/phy/mdio_bus.c:63): No description found for parameter 'd'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Seems that skb goes into void unless something magic happened
in pskb_expand_head in case of failure.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The checks for ensuring that the array indices are inside the range
were flipped.
Reported-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The driver just sets ->llseek to NULL. It should also clear FMODE_LSEEK to
tell the VFS that seeks are not supported.
Pointed out by Christoph Hellwig.
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2.6.27-git2 kernel build fails with allyesconfig on powerpc with
build error
<introduced by commit 01f2e4ead2c51226ed1283ef6a8388ca6f4cff8f>
CC drivers/net/enic/enic_main.o
drivers/net/enic/enic_main.c: In function âenic_queue_wq_skb_tsoâ:
drivers/net/enic/enic_main.c:576: error: implicit declaration of function âcsum_ipv6_magicâ
make[3]: *** [drivers/net/enic/enic_main.o] Error 1
<introduced by commit c4e84bde1d595d857d3c74b49b9c45cc770df792>
drivers/net/qlge/qlge_main.c: In function âql_tsoâ:
drivers/net/qlge/qlge_main.c:1862: error: implicit declaration of function âcsum_ipv6_magicâ
make[3]: *** [drivers/net/qlge/qlge_main.o] Error 1
<introduced by commit 95252236e73e789dd186ce796a2abc60b3a61ebe>
drivers/net/jme.c: In function âjme_tx_tsoâ:
drivers/net/jme.c:1784: error: implicit declaration of function âcsum_ipv6_magicâ
make[2]: *** [drivers/net/jme.o] Error 1
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
According to Christoph Hellwig's advice, we really don't need
a ->list to handle one xattr's list. Just a map from index to
xattr prefix is enough. And I also refactor the old list method
with the reference from fs/xfs/linux-2.6/xfs_xattr.c and the
xattr list method in btrfs.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
According to Christoph Hellwig's advice, the hash value of EA
is only calculated by its suffix.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
Per Christoph Hellwig's suggestion - don't split these up. It's not like we
gained much by having the two tiny files around.
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
i and b_len don't really need to be u64's. Xattr extent lengths should be
limited by the VFS, and then the size of our on-disk length field.
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
As Mark mentioned, it may be time-consuming when we remove the
empty xattr bucket, so this patch try to let empty bucket exist
in xattr operation. The modification includes:
1. Remove the functin of bucket and extent record deletion during
xattr delete.
2. In xattr set:
1) Don't clean the last entry so that if the bucket is empty,
the hash value of the bucket is the hash value of the entry
which is deleted last.
2) During insert, if we meet with an empty bucket, just use the
1st entry.
3. In binary search of xattr bucket, use the bucket hash value(which
stored in the 1st xattr entry) to find the right place.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
During the process of xatt insertion, we use binary search
to find the right place and "low" is set to it. But when
there is one xattr which has the same name hash as the inserted
one, low is the wrong value. So set it to the right position.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
Patch adds check for [no]user_xattr in ocfs2_show_options() that completes
the list of all mount options.
Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
ocfs2 wants JBD2 for many reasons, not the least of which is that JBD is
limiting our maximum filesystem size.
It's a pretty trivial change. Most functions are just renamed. The
only functional change is moving to Jan's inode-based ordered data mode.
It's better, too.
Because JBD2 reads and writes JBD journals, this is compatible with any
existing filesystem. It can even interact with JBD-based ocfs2 as long
as the journal is formated for JBD.
We provide a compatibility option so that paranoid people can still use
JBD for the time being. This will go away shortly.
[ Moved call of ocfs2_begin_ordered_truncate() from ocfs2_delete_inode() to
ocfs2_truncate_for_delete(). --Mark ]
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
Now that ocfs2 limits inode numbers to 32bits, add a mount option to
disable the limit. This parallels XFS. 64bit systems can handle the
larger inode numbers.
[ Added description of inode64 mount option in ocfs2.txt. --Mark ]
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
ocfs2 inode numbers are block numbers. For any filesystem with less
than 2^32 blocks, this is not a problem. However, when ocfs2 starts
using JDB2, it will be able to support filesystems with more than 2^32
blocks. This would result in inode numbers higher than 2^32.
The problem is that stat(2) can't handle those numbers on 32bit
machines. The simple solution is to have ocfs2 allocate all inodes
below that boundary.
The suballoc code is changed to honor an optional block limit. Only the
inode suballocator sets that limit - all other allocations stay unlimited.
The biggest trick is to grow the inode suballocator beneath that limit.
There's no point in allocating block groups that are above the limit,
then rejecting their elements later on. We want to prevent the inode
allocator from ever having block groups above the limit. This involves
a little gyration with the local alloc code. If the local alloc window
is above the limit, it signals the caller to try the global bitmap but
does not disable the local alloc file (which can be used for other
allocations).
[ Minor cleanup - removed an ML_NOTICE comment. --Mark ]
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
In ocfs2_xattr_free_block, we take a cluster lock on xb_alloc_inode while we
have a transaction open. This will deadlock the downconvert thread, so fix
it.
We can clean up how xattr blocks are removed while here - this patch also
moves the mechanism of releasing xattr block (including both value, xattr
tree and xattr block) into this function.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
In ocfs2_extend_trans, when we can't extend the current
transaction, it will commit current transaction and restart
a new one. So if the previous credits we have allocated aren't
used(the block isn't dirtied before our extend), we will not
have enough credits for any future operation(it will cause jbd
complain and bug out). So check this and re-extend it.
Signed-off-by: Tao Ma <tao.ma@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
The original get/put_extent_tree() functions held a reference on
et_root_bh. However, every single caller already has a safe reference,
making the get/put cycle irrelevant.
We change ocfs2_get_*_extent_tree() to ocfs2_init_*_extent_tree(). It
no longer gets a reference on et_root_bh. ocfs2_put_extent_tree() is
removed. Callers now have a simpler init+use pattern.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
struct ocfs2_extent_tree_operations provides methods for the different
on-disk btrees in ocfs2. Describing what those methods do is probably a
good idea.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
We now have three different kinds of extent trees in ocfs2: inode data
(dinode), extended attributes (xattr_tree), and extended attribute
values (xattr_value). There is a nice abstraction for them,
ocfs2_extent_tree, but it is hidden in alloc.c. All the calling
functions have to pick amongst a varied API and pass in type bits and
often extraneous pointers.
A better way is to make ocfs2_extent_tree a first-class object.
Everyone converts their object to an ocfs2_extent_tree() via the
ocfs2_get_*_extent_tree() calls, then uses the ocfs2_extent_tree for all
tree calls to alloc.c.
This simplifies a lot of callers, making for readability. It also
provides an easy way to add additional extent tree types, as they only
need to be defined in alloc.c with a ocfs2_get_<new>_extent_tree()
function.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
A couple places check an extent_tree for a valid inode. We move that
out to add an eo_insert_check() operation. It can be called from
ocfs2_insert_extent() and elsewhere.
We also have the wrapper calls ocfs2_et_insert_check() and
ocfs2_et_sanity_check() ignore NULL ops. That way we don't have to
provide useless operations for xattr types.
Signed-off-by: Joel Becker <joel.becker@oracle.com>
Signed-off-by: Mark Fasheh <mfasheh@suse.com>
