The magicmouse driver needs to setup the input mapping
after reports are parsed but before device is registered.
Change-Id: Ic3a0ff4fc056f5d374bb7ea1bd831a175c690b0b
Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com>
Add input_register callback which gets called after
hid_configure_usage is called for all the reports
and before the input device is registered. This allows
individual drivers to do extra work like input mapping just
before device registration.
Based on discussions with David Herrmann <dh.herrmann@googlemail.com>
Change-Id: Idab6fb4f7b1e5e569bd0410967288717e9d34c98
Signed-off-by: Jaikumar Ganesh <jaikumarg@android.com>
There is a
/proc/net/xt_qtaguid/iface/<iface>/{rx_bytes,rx_packets,tx_bytes,...}
but for better convenience and to avoid getting overly stale net/dev stats
we now have
/proc/net/xt_qtaguid/iface_stat_all
which outputs lines of:
iface_name active rx_bytes rx_packets tx_bytes tx_packets
net_dev_rx_bytes net_dev_rx_packets net_dev_tx_bytes net_dev_tx_packets
Change-Id: I12cc10d2d123b86b56d4eb489b1d77b2ce72ebcf
Signed-off-by: JP Abgrall <jpa@google.com>
ARM errata 727915 for PL310 has been updated to include a new
workaround required for PL310 r2p0 for l2x0_flush_all, which also
affects l2x0_clean_all in my testing. For r2p0, clean or flush
each set/way individually. For r3p0 or greater, use the debug
register for cleaning and flushing.
Requires exporting the cache_id, sets and ways detected in the
init function for later use.
Change-Id: I215055cbe5dc7e4e8184fb2befc4aff672ef0a12
Signed-off-by: Colin Cross <ccross@android.com>
get_loadavg doesn't work as intended. According to the comments, it
should be returning an average over a few seconds, but it is actually
reading the instantaneous load. It is almost always returning 0, but
can sometimes, depending on workload, spike very high into the hundreds
even when the average cpu load is under 10%. Disable it for now.
Change-Id: I63ed100af1cf9463549939b8113ed83676db5f86
Signed-off-by: Colin Cross <ccross@android.com>
The interactive governor relies on quirks of the Tegra 2 cpufreq
implementation for handling SMP systems where the CPUs do not have
separate rate controls. It needs to determine the maximum rate
for all CPUs covered by the policy and set that speed.
Change-Id: I1ed9fa171e5a9c45a1fa5944e3fa823eb157e81f
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Most net devs will not reset their stats when just going down/up,
unless a NETDEV_UNREGISTER was notified.
But some devs will not send out a NETDEV_UNREGISTER but still
reset their stats just before a NETDEV_UP.
Now we just track the dev stats during NETDEV_DOWN... just in case.
Then on NETDEV_UP we check the stats: if the device didn't do a
NETDEV_UNREGISTER and a prior NETDEV_DOWN captured stats, then we treat
it as an UNREGISTER and save the totals from the stashed values.
Added extra netdev event debugging.
Change-Id: Iec79e74bfd40269aa3e5892f161be71e09de6946
Signed-off-by: JP Abgrall <jpa@google.com>
- Fix no scan problem for cfg80211 when Scan Event missed
- Improve logic to generate Event via cfg80211 when FW hangs
- Fix a crash on Android driver removal
- DHD read has chance to crash under long stress : fix (dhd_sdio.c)
- Fix power consumption issue as sending disassoc explicitly
- Change the logic for listen timer to solve memory leak and guarantee
listen timing
- Adding wl_cfg80211_get_station for HostAPD
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
If we go through connected->configured->disconnected cycle very quickly,
it is possible that we may not generate a disconnect uevent to userspace.
Connected+configured could have happened before the work item got
executed, and thus would not have updated the sw_connected state. On
the disconnect, it would have noticed that a config is no longer there
but since sw_connected was still 0, it would not have sent the
disconnect event.
Change-Id: Id71175f784e3e1cf3f828bd8b24fceea1078a06b
Signed-off-by: Dima Zavin <dima@android.com>
We should composite_disconnect *before* updating our internal
state and sending uevent to userspace.
Also, hold cdev->lock while updating internal state.
Change-Id: If66a5a4f7d4a102a44aefc3ce4a154a5a1517dcf
Signed-off-by: Dima Zavin <dima@android.com>
Add a board file option to gpio_input devices to make
calling enable_irq_wake conditional. Also disable the
wake irq when removing the device.
Change-Id: If933b9d3a751d89fa95ae3b7f739dfe70fcb23c8
Signed-off-by: Mike J. Chen <mjchen@sta.samsung.com>
vfp_pm_suspend should save the VFP state in suspend after
any lazy context switch. If it only saves when the VFP is enabled,
the state can get lost when, on a UP system:
Thread 1 uses the VFP
Context switch occurs to thread 2, VFP is disabled but the
VFP context is not saved
Thread 2 initiates suspend
vfp_pm_suspend is called with the VFP disabled, and the unsaved
VFP context of Thread 1 in the registers
Modify vfp_pm_suspend to save the VFP context whenever
vfp_current_hw_state is not NULL.
Change-Id: I91f29722d256a3afc1cc04df8b227541434ccffb
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Barry Song <bs14@csr.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Colin Cross <ccross@android.com>
Prevent a preemption event causing the initialized VFP state being
overwritten by ensuring that the VFP hardware access is disabled
prior to starting initialization. We can then do this in safety
while still allowing preemption to occur.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fix a hole in the VFP thread migration. Lets define two threads.
Thread 1, we'll call 'interesting_thread' which is a thread which is
running on CPU0, using VFP (so vfp_current_hw_state[0] =
&interesting_thread->vfpstate) and gets migrated off to CPU1, where
it continues execution of VFP instructions.
Thread 2, we'll call 'new_cpu0_thread' which is the thread which takes
over on CPU0. This has also been using VFP, and last used VFP on CPU0,
but doesn't use it again.
The following code will be executed twice:
cpu = thread->cpu;
/*
* On SMP, if VFP is enabled, save the old state in
* case the thread migrates to a different CPU. The
* restoring is done lazily.
*/
if ((fpexc & FPEXC_EN) && vfp_current_hw_state[cpu]) {
vfp_save_state(vfp_current_hw_state[cpu], fpexc);
vfp_current_hw_state[cpu]->hard.cpu = cpu;
}
/*
* Thread migration, just force the reloading of the
* state on the new CPU in case the VFP registers
* contain stale data.
*/
if (thread->vfpstate.hard.cpu != cpu)
vfp_current_hw_state[cpu] = NULL;
The first execution will be on CPU0 to switch away from 'interesting_thread'.
interesting_thread->cpu will be 0.
So, vfp_current_hw_state[0] points at interesting_thread->vfpstate.
The hardware state will be saved, along with the CPU number (0) that
it was executing on.
'thread' will be 'new_cpu0_thread' with new_cpu0_thread->cpu = 0.
Also, because it was executing on CPU0, new_cpu0_thread->vfpstate.hard.cpu = 0,
and so the thread migration check is not triggered.
This means that vfp_current_hw_state[0] remains pointing at interesting_thread.
The second execution will be on CPU1 to switch _to_ 'interesting_thread'.
So, 'thread' will be 'interesting_thread' and interesting_thread->cpu now
will be 1. The previous thread executing on CPU1 is not relevant to this
so we shall ignore that.
We get to the thread migration check. Here, we discover that
interesting_thread->vfpstate.hard.cpu = 0, yet interesting_thread->cpu is
now 1, indicating thread migration. We set vfp_current_hw_state[1] to
NULL.
So, at this point vfp_current_hw_state[] contains the following:
[0] = &interesting_thread->vfpstate
[1] = NULL
Our interesting thread now executes a VFP instruction, takes a fault
which loads the state into the VFP hardware. Now, through the assembly
we now have:
[0] = &interesting_thread->vfpstate
[1] = &interesting_thread->vfpstate
CPU1 stops due to ptrace (and so saves its VFP state) using the thread
switch code above), and CPU0 calls vfp_sync_hwstate().
if (vfp_current_hw_state[cpu] == &thread->vfpstate) {
vfp_save_state(&thread->vfpstate, fpexc | FPEXC_EN);
BANG, we corrupt interesting_thread's VFP state by overwriting the
more up-to-date state saved by CPU1 with the old VFP state from CPU0.
Fix this by ensuring that we have sane semantics for the various state
describing variables:
1. vfp_current_hw_state[] points to the current owner of the context
information stored in each CPUs hardware, or NULL if that state
information is invalid.
2. thread->vfpstate.hard.cpu always contains the most recent CPU number
which the state was loaded into or NR_CPUS if no CPU owns the state.
So, for a particular CPU to be a valid owner of the VFP state for a
particular thread t, two things must be true:
vfp_current_hw_state[cpu] == &t->vfpstate && t->vfpstate.hard.cpu == cpu.
and that is valid from the moment a CPU loads the saved VFP context
into the hardware. This gives clear and consistent semantics to
interpreting these variables.
This patch also fixes thread copying, ensuring that t->vfpstate.hard.cpu
is invalidated, otherwise CPU0 may believe it was the last owner. The
hole can happen thus:
- thread1 runs on CPU2 using VFP, migrates to CPU3, exits and thread_info
freed.
- New thread allocated from a previously running thread on CPU2, reusing
memory for thread1 and copying vfp.hard.cpu.
At this point, the following are true:
new_thread1->vfpstate.hard.cpu == 2
&new_thread1->vfpstate == vfp_current_hw_state[2]
Lastly, this also addresses thread flushing in a similar way to thread
copying. Hole is:
- thread runs on CPU0, using VFP, migrates to CPU1 but does not use VFP.
- thread calls execve(), so thread flush happens, leaving
vfp_current_hw_state[0] intact. This vfpstate is memset to 0 causing
thread->vfpstate.hard.cpu = 0.
- thread migrates back to CPU0 before using VFP.
At this point, the following are true:
thread->vfpstate.hard.cpu == 0
&thread->vfpstate == vfp_current_hw_state[0]
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rename this branch to more accurately reflect why its taken, rather
than what the following code does. It is the only caller of this code.
This helps to clarify following changes, yet this change results in no
actual code change.
Document the VFP hardware state at the target of this branch.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Rename the slightly confusing 'last_VFP_context' variable to be more
descriptive of what it actually is. This variable stores a pointer
to the current owner's vfpstate structure for the context held in the
VFP hardware.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When a process doesn't have /dev/xt_qtaguid open, only warn once
instead of for every ctrl access.
Change-Id: I98a462a8731254ddc3bf6d2fefeef9823659b1f0
Signed-off-by: JP Abgrall <jpa@google.com>
It is possible that while one driver has already suspended,
another driver calls otg_id_notify() because it has not yet been
suspended. It would then be possible for the suspended driver's
detect callback to be called. This is undesirable.
Introduce new otg_id_suspend/otg_id_resume functions that
keep a suspended count, and if a notification happens while
someone is suspended, that notification is deferred until
all the drivers are resumed. If the notification happens before
the last driver is suspended, that suspend will be aborted
and once the final driver resumes through otg_id_resume, the
notification will be delivered.
Change-Id: I32fd32bec65e366e5f97a25c15255d94773b85b3
Signed-off-by: Dima Zavin <dima@android.com>
* Added global resource tracking based on tags.
- Can be put into passive mode via
/sys/modules/xt_qtaguid/params/tag_tracking_passive
- The number of socket tags per UID is now limited
- Adding /dev/xt_qtaguid that each process should open before starting
to tag sockets. A later change will make it a "must".
- A process should not create new tags unless it has the dev open.
A later change will make it a must.
- On qtaguid_resources release, the process' matching socket tag info
is deleted.
* Support run-time debug mask via /sys/modules parameter "debug_mask".
* split module into prettyprinting code, includes, main.
* Removed ptrdiff_t usage which didn't work in all cases.
Change-Id: I4a21d3bea55d23c1c3747253904e2a79f7d555d9
Signed-off-by: JP Abgrall <jpa@google.com>
It was using ANDROID_ALARM_ELAPSED_REALTIME_WAKEUP_MASK as an
index.
Change-Id: I919860cc71254453e382616bce9fd5455802cb3d
Signed-off-by: JP Abgrall <jpa@google.com>
There is no need to take a wakelock for delayed lazy disable
work, it will be cancelled in the suspend handler and force
disabled. Only take the wakelock when the detect work is
queued, and make sure to drop the wakelock if the work is
cancelled.
Change-Id: I1e507a5f98848954ea21d45e23b6192c3132a349
Signed-off-by: Colin Cross <ccross@android.com>
- Add BT-Coex support to cfg80211
- Add private event logic to cfg80211 when FW hangs
- Reduce passive dwell time to 130 ms
- Fix proptx initialize fail issue
- Implement codes for WPS2.0 using cfg80211
- Clean any left virtual interfaces in primary dhd_stop context
- Skip waiting for rtnl_lock in cfg80211 callback if already taken
- Skip writing to file FW trap info
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
This patch introduces the helper of ehci_sync_mem to flush
qtd/qh into memory immediately on some ARM, so that HC can
see the up-to-date qtd/qh descriptor asap.
This patch fixs one performance bug on ARM Cortex A9 dual core
platform, which has been reported on quite a few ARM machines
(OMAP4, Tegra 2, snowball...), see details from link of
https://bugs.launchpad.net/bugs/709245.
The patch has been tested ok on OMAP4 panda A1 board, and the
performance of 'dd' over usb mass storage can be increased from
4~5MB/sec to 14~16MB/sec after applying this patch.
Change-Id: I7994c58a1001c7f46f13e09420328a3916bbfcef
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Commit 330605423c fixed l2cap conn establishment for non-ssp remote
devices by not setting HCI_CONN_ENCRYPT_PEND every time conn security
is tested (which was always returning failure on any subsequent
security checks).
However, this broke l2cap conn establishment for ssp remote devices
when an ACL link was already established at SDP-level security. This
fix ensures that encryption must be pending whenever authentication
is also pending.
Change-Id: I6876ea5134e90d1f3d0f84e8ed40b92977b3df64
Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
This is basically a more generic respin of 23746a6 ("HID: magicmouse: ignore
'ivalid report id' while switching modes") which got reverted later by
c3a492.
It turns out that on some configurations, this is actually still the case
and we are not able to detect in runtime.
The device reponds with 'invalid report id' when feature report switching it
into multitouch mode is sent to it.
This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK
on Sent Reports"), but since this commit, it propagates -EIO from the _raw
callback .
So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
how the device reacts in normal mode.
Sad, but following reality.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022
Change-Id: Ice409708bb7bd1b43bd86adde121a353f8d03835
Reported-by: Chase Douglas <chase.douglas@canonical.com>
Reported-by: Jaikumar Ganesh <jaikumarg@android.com>
Tested-by: Chase Douglas <chase.douglas@canonical.com>
Tested-by: Jaikumar Ganesh <jaikumarg@android.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Turns out that some devices don't call the notifier chains
with NETDEV_UNREGISTER.
So now we only track up/down as the points for tracking
active/inactive transitions and saving the get_dev_stats().
Change-Id: I948755962b4c64150b4d04f294fb4889f151e42b
Signed-off-by: JP Abgrall <jpa@google.com>
Suspend attempts can abort when the FUSE daemon is already frozen
and a client is waiting uninterruptibly for a response, causing
freezing of tasks to fail.
Use the freeze-friendly wait API, but disregard other signals.
Change-Id: Icefb7e4bbc718ccb76bf3c04daaa5eeea7e0e63c
Signed-off-by: Todd Poynor <toddpoynor@google.com>
Bug discovered by Jan Kara:
Finally, commit 1449032be1 returned back
the old IO submission code but apparently it forgot to return the old
handling of uninitialized buffers so we unconditionnaly call
block_write_full_page() without specifying end_io function. So AFAICS
we never convert unwritten extents to written in some cases. For
example when I mount the fs as: mount -t ext4 -o
nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do
int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600);
char buf[1024];
memset(buf, 'a', sizeof(buf));
fallocate(fd, 0, 0, 16384);
write(fd, buf, sizeof(buf));
I get a file full of zeros (after remounting the filesystem so that
pagecache is dropped) instead of seeing the first KB contain 'a's.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Change-Id: I349e4e807d2f8bc3573a5e1b2393212e00ca7650
Signed-off-by: Ken Sumrall <ksumrall@android.com>
If the console_lock was held while the system was rebooted, the messages
in the temporary logbuffer would not have propogated to all the console
drivers.
This force releases the console lock if it failed to be acquired.
Change-Id: I193dcf7b968be17966833e50b8b8bc70d5d9fe89
Signed-off-by: Dima Zavin <dima@android.com>
/proc/net/xt_qtaguid/ctrl will now show:
active tagged sockets: lines of "sock=%p tag=0x%llx (uid=%u)"
sockets_tagged, : the number of sockets successfully tagged.
sockets_untagged: the number of sockets successfully untagged.
counter_set_changes: ctrl counter set change requests.
delete_cmds: ctrl delete commands completed.
iface_events: number of NETDEV_* events handled.
match_found_sk: sk found in skbuff without ct assist.
match_found_sk_in_ct: the number of times the connection tracker found
a socket for us. This happens when the skbuff didn't have info.
match_found_sk_none: the number of times no sk could be determined
successfully looked up. This indicates we don't know who the
data actually belongs to. This could be unsolicited traffic.
Change-Id: I3a65613bb24852e1eea768ab0320a6a7073ab9be
Signed-off-by: JP Abgrall <jpa@google.com>
