This is V5 of the SuperH Mobile I2C Controller Driver. A simple Master
only driver for the I2C block included in processors such as sh7343,
sh7722 and sh7723. Tested on a sh7722 MigoR using a rs5c732b rtc.
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Simply use "depends on BLACKFIN" (which is technically correct) and just
document which machines have the device.
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Blackfin TWI controller hardware pin should be requested from GPIO port controller
Before BF54x, there is no need to do this. But as long as BF54x and BF52x
are supported by this generic driver, the missing pin mux operation should be
added.
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
- Dynamic alloc the resource of TWI driver data according to board information
- TWI register read/write accessor based on dynamic regs_base
- Support TWI0/TWI1 for BF54x
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
- Create a new mode TWI_I2C_MODE_REPEAT.
- No change to smbus operation.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bryan Wu <cooloney@kernel.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
__FUNCTION__ is gcc-specific, use __func__.
Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Driver for I2C interfaces in master mode on SH7760.
Signed-off-by: Manuel Lauss <mano@roarinelk.homelinux.net>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Split the handling of the I2C_RDWR and I2C_SMBUS ioctls to their own
functions. This limits the stack usage, saves one level of indentation
and makes the code more readable.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
This patch allows the i2c-ibm_iic driver to be built either as an ocp
driver or an of_platform driver. This allows it to run under the powerpc
arch but maintains backward compatibility with the ppc arch.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Change the log levels based on feedback from linxppc-dev.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The separation between algorithm and adapter was unsharp at places. This was
partly hidden by the fact, that the ISA-driver allowed just one instance and
had all private data in static variables. This patch makes neccessary
preparations to add a platform driver on top of the algorithm, while still
supporting ISA. Note: Due to lack of hardware, the ISA-driver could not be
tested except that it builds.
Concerning the core struct i2c_algo_pca_data:
- A private data field was added, all hardware dependant data may go here.
Similar to other algorithms, now a pointer to this data is passed to the
adapter's functions. In order to make as less changes as possible to the
ISA-driver, it leaves the private data empty and still only uses its static
variables.
- A "reset_chip" function pointer was added; such a functionality must come
from the adapter, not the algorithm.
- use a variable "i2c_clock" instead of a function pointer "get_clock",
allowing for write access to a default in case a wrong value was supplied.
In the algorithm-file:
- move "i2c-pca-algo.h" into "linux/i2c-algo-pca.h"
- now using per_instance timeout values (i2c_adap->timeout)
- error messages specify the device, not only the driver name
- restructure initialization to easily support "i2c_add_numbered_adapter"
- drop "retries" and "own" (i2c address) as they were unused
(The state-machine for I2C-communication was not touched.)
In the ISA-driver:
- adapt to new algorithm
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Remove trailing whitespaces to make further patches more readable. Also remove
an unnecessary UTF-char for simplicity ("us" for microseconds is fine enough).
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The algorithm drivers are helper drivers that are selected automatically
as needed. There's no point in listing them in the config menu, it can
only confuse users and waste their time.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
- remove unused 'irq' argument from pfm_do_interrupt_handler()
- remove pointless cast to void*
- add KERN_xxx prefix to printk()
- remove braces around singleton C statement
- in tioce_provider.c, start tioce_dma_consistent() and
tioce_error_intr_handler() function declarations in column 0
This change's main purpose is to prepare for the patchset in
jgarzik/misc-2.6.git#irq-remove, that explores removal of the
never-used 'irq' argument in each interrupt handler.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
There are many notify_die() and almost all take same style with
ia64_mca_spin(). This patch defines macros and replace them all,
to reduce lines and to improve readability.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
There are 3 hooks in MCA handler, but this DIE_MCA_MONARCH_PROCESS
event does not notified other than for the first monarch.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
While testing with CONFIG_VIRT_CPU_ACCOUNTING=y, I found that
I occasionally get very huge system time in some threads.
So I dug the issue and finally noticed that it was caused
because of an interrupt which interrupt in the following window:
> [arch/ia64/kernel/entry.S: (!CONFIG_PREEMPT && CONFIG_VIRT_CPU_ACCOUNTING)]
>
> ENTRY(ia64_leave_syscall)
> :
> (pUStk) rsm psr.i
> cmp.eq pLvSys,p0=r0,r0 // pLvSys=1: leave from syscall
> (pUStk) cmp.eq.unc p6,p0=r0,r0 // p6 <- pUStk
> .work_processed_syscall:
> adds r2=PT(LOADRS)+16,r12
> (pUStk) mov.m r22=ar.itc // fetch time at leave
> adds r18=TI_FLAGS+IA64_TASK_SIZE,r13
> ;;
> <<< window: from here >>>
> (p6) ld4 r31=[r18] // load current_thread_info()->flags
> ld8 r19=[r2],PT(B6)-PT(LOADRS)
> adds r3=PT(AR_BSPSTORE)+16,r12
> ;;
> mov r16=ar.bsp
> ld8 r18=[r2],PT(R9)-PT(B6)
> (p6) and r15=TIF_WORK_MASK,r31 // any work other than TIF_SYSCALL_TRACE?
> ;;
> ld8 r23=[r3],PT(R11)-PT(AR_BSPSTORE)
> (p6) cmp4.ne.unc p6,p0=r15, r0 // any special work pending?
> (p6) br.cond.spnt .work_pending_syscall
> ;;
> ld8 r9=[r2],PT(CR_IPSR)-PT(R9)
> ld8 r11=[r3],PT(CR_IIP)-PT(R11)
> (pNonSys) break 0 // bug check: we shouldn't be here if pNonSys is TRUE!
> ;;
> invala
> <<< window: to here >>>
> rsm psr.i | psr.ic // turn off interrupts and interruption collection
If pUStk is true, it means we are going to return user mode, hence we fetch
ar.itc to get time at leave from system.
It seems that it is not possible to interrupt the window if pUStk is true,
because interrupts are disabled early. And also disabling interrupt makes
sense because it is safe for referring current_thread_info()->flags.
However interrupting the window while pUStk is true was possible.
The route was:
ia64_trace_syscall
-> .work_pending_syscall_end
-> .work_processed_syscall
Only in case entering the window from this route, interrupts are enabled
during in the window even if pUStk is true. I suppose interrupts must be
disabled here anyway if pUStk is true.
I'm not sure but afraid that what kind of bad effect were there, other
than crazy system time which I found.
FYI, there was a commit 6f6d75825d that
points out a bug at same point(exit of ia64_trace_syscall) in 2006.
It can be said that there was an another bug.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Samsung USB remotes (0419:0001) report six keys via standard HID usage pages
(arrow keys, OK, Power). Kernel 2.6.25 maps those to input events (in addition
to the hiddev report). The remaining 43 keys are reported via proprietary HID
report page and therefore by hiddev only.
Applications using hiddev and input device might process the 6 standard keys
twice. To avoid this, the input device will be suppressed for the Samsung
remote with a quirk entry, forcing to use the hiddev device only.
LIRC already contains the proper support.
Signed-off-by: Robert Schedel <r.schedel@yahoo.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Jeremy Robertson reports that GTCO engineers made a mistake and we don't
need 0x60x GTCO product ids blacklisted.
This mostly reverts dda3fd35, but leaves PID 0x1007 intact.
Reported-by: Jeremy Roberson <jeremy.roberson@einstruction.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
I have people whining about using these headers in userspace, and they have
__KERNEL__ markings which implies they're supposed to be exported. I also
added the required linux/types.h include to hidraw.h since it uses the __u##
kernel types.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Cc: Jiri Kosina <jikos@jikos.cz>
Cc: Dmitry Torokhov <dtor@mail.ru>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is no need to keep a few years old ThrustMaster force-feedback
driver as experimental.
HID_FF is currently marked experimental anyway, so this is even redundant.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a window:
task A task B
spin_lock_irq(&usbhid->inlock); /* Sync with error handler */
usb_set_intfdata(intf, NULL);
spin_unlock_irq(&usbhid->inlock);
usb_kill_urb(usbhid->urbin);
usb_kill_urb(usbhid->urbout);
usb_kill_urb(usbhid->urbctrl);
del_timer_sync(&usbhid->io_retry);
cancel_work_sync(&usbhid->reset_work);
if (!hid->open++) {
res = usb_autopm_get_interface(usbhid->intf);
if (res < 0) {
hid->open--;
return -EIO;
}
}
if (hid_start_in(hid))
if (hid->claimed & HID_CLAIMED_INPUT)
hidinput_disconnect(hid);
in which an open() to an already disconnected device will submit an URB
to an undead device. In case disconnect() was called by an ioctl, this'll
oops. Fix by introducing a new flag and checking it in hid_start_in().
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This patch makes the following needlessly global functions static:
- hid-core.c:hid_input_field()
- usbhid/hid-quirks.c:usbhid_modify_dquirk()
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The numbered reports need to be passed properly to hidraw (i.e. with the first
data field indicating the report number), otherwise userspace has no idea
about the identification of the report.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This moves the misplaced rdesc quirk to the place where it belongs.
Reported-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add force feedback support for Logitech Rumblepad 2.
Tested-By: Edgar Simo <bobbens@gmail.com>
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
To check paramters even if debug is disabled, convert dbg_hid
to inline function with __attribute__(format) checking.
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix these sparse warnings:
.../hid/hid-core.c💯15: warning: incorrect type in assignment (different signedness)
.../hid/hid-core.c💯15: expected signed int [usertype] *value
.../hid/hid-core.c💯15: got unsigned int *<noident>
by unsigned -> s32
.../hid/hid-input-quirks.c:336:10: warning: Using plain integer as NULL pointer
by 0 -> NULL
.../hid/usbhid/hid-core.c:786:46: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:786:46: expected int *max
.../hid/usbhid/hid-core.c:786:46: got unsigned int *<noident>
.../hid/usbhid/hid-core.c:787:47: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:787:47: expected int *max
.../hid/usbhid/hid-core.c:787:47: got unsigned int *<noident>
.../hid/usbhid/hid-core.c:788:48: warning: incorrect type in argument 3 (different signedness)
.../hid/usbhid/hid-core.c:788:48: expected int *max
.../hid/usbhid/hid-core.c:788:48: got unsigned int *<noident>
by int -> unsigned int
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Currently using debug=1 with hid module prints out all sent and received
reports to the kernel log, while in many cases we only want to see the
report descriptors and hid-input mappings that are printed when a device
is probed.
Add new level debug=2, and only dump the report traffic with that level.
Signed-off-by: Anssi Hannula <anssi.hannula@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This must be the weirdest failure yet. My external disk stops processing
the storage commands the moment it receives a GET_REPORT. The firmware
does not crash; if I do rmmod hid, then SET-INTERFACE restores normal
operations. Still, I cannot live without the keyboard when I want backup
my files. Adding the NOGET quirk fixes this problem for me.
Signed-off-by: Pete Zaitcev <zaitcev@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
This device has reports lower logical maximum compared to the real
usages for Zoom+ and Zoom- it emits.
This patch bumps the values in the report descriptor up, and also
adjusts HID_MAX_USAGE accordingly.
Reported-by: Khelben Blackstaff <eye.of.the.8eholder@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Microsoft's wireless desktop receiver (Model 1028) has a bug in the report
descriptor -- namely, in four seperate places it uses USAGE_MIN and _MAX when
it quite obviously doesn't intend to.
In other words, it reports that it has pretty much _everything_ in 'consumer'
and 'generic desktop'. And then the X evdev driver believes I have a mouse
with 36 absolute axes and a huge pile of keys and buttons, when I in fact,
should have zero. 255/256 in three of the cases, and 0-1024 in another.
This patch fixes the report descriptor of this device before it enters the HID
parser.
Signed-off-by: Jim Duchek <jim.duchek@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Many vendors highspeed devices give erroneously fullspeed interval value in
endpoint descriptor for interrupt endpoints. This quirk fixes up that by
recalculating the right value for highspeed device.
At the time of hid configuration this quirk calculates which highspeed interval
value gives same interval delay as, or next smaller then, what it would be if
the original value would be interpreted as fullspeed value. In subsequent urbs
that new value is used instead.
Forming the 'hid->name' in usb_hid_config() was moved up to accommodate more
descriptive printk reporting the fixup.
In this patch the quirk is set for one such device: Afatech DVB-T 2 infrared
HID-keyboard. It reports value 16 which means 4,069s in highspeed while
obviously 16ms was intended. In this case quirk calculates new value to be 8
which gives when interpreted as highspeed value 16ms as wanted. The behavior of
the device was verified to be what expected both before and after the patch.
Signed-off-by: Pekka Sarnila <sarnila@adit.fi>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix build failure in hiddev_ioctl with gcc 3.2:
http://bugzilla.kernel.org/show_bug.cgi?id=10121
The trick is to move the handling of ioctls which need to allocate
memory to separate functions.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
As it stands it's impossible to use any authentication algorithms
with an ID above 31 portably. It just happens to work on x86 but
fails miserably on ppc64.
The reason is that we're using a bit mask to check the algorithm
ID but the mask is only 32 bits wide.
After looking at how this is used in the field, I have concluded
that in the long term we should phase out state matching by IDs
because this is made superfluous by the reqid feature. For current
applications, the best solution IMHO is to allow all algorithms when
the bit masks are all ~0.
The following patch does exactly that.
This bug was identified by IBM when testing on the ppc64 platform
using the NULL authentication algorithm which has an ID of 251.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
The attached patch needs to move from -rt to mainline given preemptable RCU.
This patch fixes SELinux code that implicitly assumes that disabling
preemption prevents an RCU grace period from completing, an assumption that
is valid for Classic RCU, but not necessarily for preemptable RCU. Explicit
rcu_read_lock() calls are thus added.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
Further reduction of stack footprint (sys_pivot_root());
lose useless BKL in there, while we are at it.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Taking namespace_sem shared there isn't worth the trouble, especially with
vfsmount ID allocation about to be added. That way we know that umount_tree(),
copy_tree() and clone_mnt() are _always_ serialized by namespace_sem.
umount_tree() still needs vfsmount_lock (it manipulates hash chains, among
other things), but that's a separate story.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
