Rpi patches #1724
Closed
Rpi patches #1724
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…upt context commit f6a290b upstream. _scsih_smart_predicted_fault is called in an interrupt and therefore must allocate memory using GFP_ATOMIC. Signed-off-by: Anton Blanchard <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7e1e7ea upstream. The error exit path leaks preempt count. Add the missing put_cpu(). Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Yi Zou <[email protected]> Signed-off-by: James Bottomley <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 15062e6 upstream. Emmanuel noticed that when mac80211 stops the queues for aggregation that can leave a packet pending. This packet will be given to the driver after the AMPDU callback, but as a non-aggregated packet which messes up the sequence number etc. I also noticed by looking at the code that if packets are being processed while we clear the WANT_START bit, they might see it cleared already and queue up on tid_tx->pending. If the driver then rejects the new aggregation session we leak the packet. Fix both of these issues by changing this code to not stop the queues at all. Instead, let packets queue up on the tid_tx->pending queue instead of letting them get to the driver, and add code to recover properly in case the driver rejects the session. (The patch looks large because it has to move two functions to before their new use.) Reported-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 37d5993 upstream. Record the clock after the divider as that is what all SYSCLK users see. Without this the other clock configuration in the device comes out at half rate. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 5151412 upstream. struct request_queue is allocated with __GFP_ZERO so its "node" field is zero before initialization. This causes an oops if node 0 is offline in the page allocator because its zonelists are not initialized. From Dave Young's dmesg: SRAT: Node 1 PXM 2 0-d0000000 SRAT: Node 1 PXM 2 100000000-330000000 SRAT: Node 0 PXM 1 330000000-630000000 Initmem setup node 1 0000000000000000-000000000affb000 ... Built 1 zonelists in Node order, mobility grouping on. ... BUG: unable to handle kernel paging request at 0000000000001c08 IP: [<ffffffff8111c355>] __alloc_pages_nodemask+0xb5/0x870 and __alloc_pages_nodemask+0xb5 translates to a NULL pointer on zonelist->_zonerefs. The fix is to initialize q->node at the time of allocation so the correct node is passed to the slab allocator later. Since blk_init_allocated_queue_node() is no longer needed, merge it with blk_init_allocated_queue(). [[email protected]: changelog, initializing q->node] Reported-by: Dave Young <[email protected]> Signed-off-by: Mike Snitzer <[email protected]> Signed-off-by: David Rientjes <[email protected]> Tested-by: Dave Young <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 329456d upstream. This fixes a Data bus error on some SoCs. The first fix for this problem did not solve it on all devices. commit 6ae8ec2 Author: Rafał Miłecki <[email protected]> Date: Tue Jul 5 17:25:32 2011 +0200 ssb: fix init regression of hostmode PCI core In ssb_pcicore_fix_sprom_core_index() the sprom on the PCI core is accessed, but the sprom only exists when the ssb bus is connected over a PCI bus to the rest of the system and not when the SSB Bus is the main system bus. SoCs sometimes have a PCI host controller and there this code will not be executed, but there are some old SoCs with an PCI controller in client mode around and ssb_pcicore_fix_sprom_core_index() should not be called on these devices too. The PCI controller on these devices are unused, but without this fix it results in an Data bus error when it gets initialized. Cc: Michael Buesch <[email protected]> Cc: Rafał Miłecki <[email protected]> Signed-off-by: Hauke Mehrtens <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…FSLEEP transition commit 91ddff8 upstream. In drivers rtl8192ce, rtl8192cu, rtl8192se, and rtl8192de, break statements would allow ppsc->rfpwr_state to be changed to ERFSLEEP even though the device is actually in ERFOFF. Signed-off-by: Philipp Dreimann <[email protected]> Signed-off-by: Larry Finger <[email protected]> Cc: Chaoming Li <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c0d96ae upstream. Signed-off-by: Jason Chen <[email protected]> Signed-off-by: Sascha Hauer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8521478 upstream. Synaptics touchpads on several Dell laptops, particularly Vostro V13 systems, may not respond properly to PS/2 commands and queries immediately after resuming from suspend to RAM. This leads to unresponsive touchpad after suspend/resume cycle. Adding a 1-second delay after resetting the device allows touchpad to finish initializing (calibrating?) and start reacting properly. Reported-by: Daniel Manrique <[email protected]> Tested-by: Daniel Manrique <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9f57bd4 upstream. per_cpu_ptr_to_phys() incorrectly rounds up its result for non-kmalloc case to the page boundary, which is bogus for any non-page-aligned address. This affects the only in-tree user of this function - sysfs handler for per-cpu 'crash_notes' physical address. The trouble is that the crash_notes per-cpu variable is not page-aligned: crash_notes = 0xc08e8ed4 PER-CPU OFFSET VALUES: CPU 0: 3711f000 CPU 1: 37129000 CPU 2: 37133000 CPU 3: 3713d000 So, the per-cpu addresses are: crash_notes on CPU 0: f7a07ed4 => phys 36b57ed4 crash_notes on CPU 1: f7a11ed4 => phys 36b4ded4 crash_notes on CPU 2: f7a1bed4 => phys 36b43ed4 crash_notes on CPU 3: f7a25ed4 => phys 36b39ed4 However, /sys/devices/system/cpu/cpu*/crash_notes says: /sys/devices/system/cpu/cpu0/crash_notes: 36b57000 /sys/devices/system/cpu/cpu1/crash_notes: 36b4d000 /sys/devices/system/cpu/cpu2/crash_notes: 36b43000 /sys/devices/system/cpu/cpu3/crash_notes: 36b39000 As you can see, all values are rounded down to a page boundary. Consequently, this is where kexec sets up the NOTE segments, and thus where the secondary kernel is looking for them. However, when the first kernel crashes, it saves the notes to the unaligned addresses, where they are not found. Fix it by adding offset_in_page() to the translated page address. -tj: Combined Eugene's and Petr's commit messages. Signed-off-by: Eugene Surovegin <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Reported-by: Petr Tesarik <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 4af3ce0 upstream. Commit cfcde11 ("IB/mlx4: Use flow counters on IBoE ports") added code that sets elements of counters[] to -1 if no counter is allocated, but then goes ahead and passes every entry to mlx4_counter_free() on shutdown. This is a bad idea, especially if MLX4_DEV_CAP_FLAG_COUNTERS isn't set so there isn't even an underlying bitmap to free from. Tested-by: Sean Hefty <[email protected]> Signed-off-by: Roland Dreier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3d3c8f9 upstream. binary_sysctl() calls sysctl_getname() which allocates from names_cache slab usin __getname() The matching function to free the name is __putname(), and not putname() which should be used only to match getname() allocations. This is because when auditing is enabled, putname() calls audit_putname *instead* (not in addition) to __putname(). Then, if a syscall is in progress, audit_putname does not release the name - instead, it expects the name to get released when the syscall completes, but that will happen only if audit_getname() was called previously, i.e. if the name was allocated with getname() rather than the naked __getname(). So, __getname() followed by putname() ends up leaking memory. Signed-off-by: Michel Lespinasse <[email protected]> Acked-by: Al Viro <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Eric Paris <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit ff05b6f upstream. An integer overflow will happen on 64bit archs if task's sum of rss, swapents and nr_ptes exceeds (2^31)/1000 value. This was introduced by commit f755a04 oom: use pte pages in OOM score where the oom score computation was divided into several steps and it's no longer computed as one expression in unsigned long(rss, swapents, nr_pte are unsigned long), where the result value assigned to points(int) is in range(1..1000). So there could be an int overflow while computing 176 points *= 1000; and points may have negative value. Meaning the oom score for a mem hog task will be one. 196 if (points <= 0) 197 return 1; For example: [ 3366] 0 3366 35390480 24303939 5 0 0 oom01 Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical memory, but it's oom score is one. In this situation the mem hog task is skipped and oom killer kills another and most probably innocent task with oom score greater than one. The points variable should be of type long instead of int to prevent the int overflow. Signed-off-by: Frantisek Hrbata <[email protected]> Acked-by: KOSAKI Motohiro <[email protected]> Acked-by: Oleg Nesterov <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…oprofilefs commit 913050b upstream. If oprofilefs_ulong_from_user() is called with count equals zero, *val remains unchanged. Depending on the implementation it might be uninitialized. Change oprofilefs_ulong_from_user()'s interface to return count on success. Thus, we are able to return early if count equals zero which avoids using *val uninitialized. Fixing all users of oprofilefs_ulong_ from_user(). This follows write syscall implementation when count is zero: "If count is zero ... [and if] no errors are detected, 0 will be returned without causing any other effect." (man 2 write) Reported-By: Mike Waychison <[email protected]> Signed-off-by: Robert Richter <[email protected]> Cc: Andrew Morton <[email protected]> Cc: oprofile-list <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit c25573b upstream. Whenever we free a slot, we know that the resulting xprt->num_reqs will be less than xprt->max_reqs, so we know that we can release at least one backlogged rpc_task. Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6c52961 upstream. After commit 06222e4 (fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek) the behaviour of llseek() was changed so that it always revalidates the file size. The bug appears to be due to a logic error in the afore-mentioned commit, which always evaluates to 'true'. Reported-by: Roel Kluin <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 111d489 upstream. Currently, the code assumes that the SEQUENCE status bits are mutually exclusive. They are not... Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 50345f1 upstream. Fix the following bug in sel_netport_insert() where rcu_dereference() should be rcu_dereference_protected() as sel_netport_lock is held. =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- security/selinux/netport.c:127 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 1 lock held by ossec-rootcheck/3323: #0: (sel_netport_lock){+.....}, at: [<ffffffff8117d775>] sel_netport_sid+0xbb/0x226 stack backtrace: Pid: 3323, comm: ossec-rootcheck Not tainted 3.1.0-rc8-fsdevel+ #1095 Call Trace: [<ffffffff8105cfb7>] lockdep_rcu_dereference+0xa7/0xb0 [<ffffffff8117d871>] sel_netport_sid+0x1b7/0x226 [<ffffffff8117d6ba>] ? sel_netport_avc_callback+0xbc/0xbc [<ffffffff8117556c>] selinux_socket_bind+0x115/0x230 [<ffffffff810a5388>] ? might_fault+0x4e/0x9e [<ffffffff810a53d1>] ? might_fault+0x97/0x9e [<ffffffff81171cf4>] security_socket_bind+0x11/0x13 [<ffffffff812ba967>] sys_bind+0x56/0x95 [<ffffffff81380dac>] ? sysret_check+0x27/0x62 [<ffffffff8105b767>] ? trace_hardirqs_on_caller+0x11e/0x155 [<ffffffff81076fcd>] ? audit_syscall_entry+0x17b/0x1ae [<ffffffff811b5eae>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff81380d7b>] system_call_fastpath+0x16/0x1b Signed-off-by: David Howells <[email protected]> Acked-by: Paul Moore <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: James Morris <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d1ee887 upstream. This patch is against the mainline v3.1 release (c3b92c8) and fixes a compile error when building for OMAP3+DSS+VOUT Acked-by: Laurent Pinchart <[email protected]> Signed-off-by: Gary Thomas <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 695c60f upstream. commit 828b1c5 ("nilfs2: add compat ioctl") incidentally broke all other NILFS compat ioctls. Make them work again. Signed-off-by: Thomas Meyer <[email protected]> Signed-off-by: Ryusuke Konishi <[email protected]> Tested-by: Ryusuke Konishi <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6107428 upstream. You didn't mean this to be a bool. Signed-off-by: Rusty Russell <[email protected]> Acked-by: Tony Olech <[email protected]> Signed-off-by: Chris Ball <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e0197aa upstream. There is a BUG when migrating a PF_EXITING proc. Since css_set_prefetch() is not called for the PF_EXITING case, find_existing_css_set() will return NULL inside cgroup_task_migrate() causing a BUG. This bug is easy to reproduce. Create a zombie and echo its pid to cgroup.procs. $ cat zombie.c \#include <unistd.h> int main() { if (fork()) pause(); return 0; } $ We are hitting this bug pretty regularly on ChromeOS. This bug is already fixed by Tejun Heo's cgroup patchset which is targetted for the next merge window: https://lkml.org/lkml/2011/11/1/356 I've create a smaller patch here which just fixes this bug so that a fix can be merged into the current release and stable. Signed-off-by: Mandeep Singh Baines <[email protected]> Downstream-Bug-Report: http://crosbug.com/23953 Reviewed-by: Li Zefan <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Cc: [email protected] Cc: [email protected] Cc: KAMEZAWA Hiroyuki <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Paul Menage <[email protected]> Cc: Olof Johansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8653be1 upstream. Check inuse variable before trying to access twl_map to prevent dereferencing of uninitialized variable. Signed-off-by: Ilya Yanok <[email protected]> Signed-off-by: Samuel Ortiz <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e6f67b8 upstream. lockdep reports a deadlock in jfs because a special inode's rw semaphore is taken recursively. The mapping's gfp mask is GFP_NOFS, but is not used when __read_cache_page() calls add_to_page_cache_lru(). Signed-off-by: Dave Kleikamp <[email protected]> Acked-by: Hugh Dickins <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f83f71f upstream. With 16-bit RGB565 colour format pixels are stored by the device in memory in the following order: | b3 | b2 | b1 | b0 | ~+-----+-----+-----+-----+ | R5 G6 B5 | R5 G6 B5 | This corresponds to V4L2_PIX_FMT_RGB565 fourcc, not V4L2_PIX_FMT_RGB565X. This change is required to avoid trouble when setting up video pipeline with the s5p-tv devices, so the colour formats at both devices can be properly matched. Signed-off-by: Sylwester Nawrocki <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 10636bc upstream. The stations always chooses 1Mbps for all trasmitting frames, whenever the AP is configured to lock the supported rates. As the max phy rate is always set with the 4th from highest phy rate, this assumption might be wrong if we have less than that. Fix that. Cc: Paul Stewart <[email protected]> Reported-by: Ajay Gummalla <[email protected]> Signed-off-by: Rajkumar Manoharan <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 123877b upstream. Check the IEEE80211_TX_CTL_ASSIGN_SEQ flag from mac80211, then decide how to set the TX_CMD_FLG_SEQ_CTL_MSK bit. Setting the wrong bit in BAR frame whill make the firmware to increment the sequence number which is incorrect and cause unknown behavior. Signed-off-by: Wey-Yi Guy <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 78feb35 upstream. My previous patch 34a5b4b iwlwifi: do not re-configure HT40 after associated Fix the case of HT40 after association on specified AP, but it break the association for some APs and cause not able to establish connection. We need to address HT40 before and after addociation. Reported-by: Andrej Gelenberg <[email protected]> Signed-off-by: Wey-Yi Guy <[email protected]> Tested-by: Andrej Gelenberg <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a41c58a upstream. If the request is to create non-root group and we fail to meet it, we should leave the root unchanged. Signed-off-by: Hillf Danton <[email protected]> Signed-off-by: Hugh Dickins <[email protected]> Acked-by: KAMEZAWA Hiroyuki <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: Balbir Singh <[email protected]> Cc: David Rientjes <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Johannes Weiner <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e30e2fd upstream. Currently, the *_global_[un]lock_online() routines are not at all synchronized with CPU hotplug. Soft-lockups detected as a consequence of this race was reported earlier at https://lkml.org/lkml/2011/8/24/185. (Thanks to Cong Meng for finding out that the root-cause of this issue is the race condition between br_write_[un]lock() and CPU hotplug, which results in the lock states getting messed up). Fixing this race by just adding {get,put}_online_cpus() at appropriate places in *_global_[un]lock_online() is not a good option, because, then suddenly br_write_[un]lock() would become blocking, whereas they have been kept as non-blocking all this time, and we would want to keep them that way. So, overall, we want to ensure 3 things: 1. br_write_lock() and br_write_unlock() must remain as non-blocking. 2. The corresponding lock and unlock of the per-cpu spinlocks must not happen for different sets of CPUs. 3. Either prevent any new CPU online operation in between this lock-unlock, or ensure that the newly onlined CPU does not proceed with its corresponding per-cpu spinlock unlocked. To achieve all this: (a) We introduce a new spinlock that is taken by the *_global_lock_online() routine and released by the *_global_unlock_online() routine. (b) We register a callback for CPU hotplug notifications, and this callback takes the same spinlock as above. (c) We maintain a bitmap which is close to the cpu_online_mask, and once it is initialized in the lock_init() code, all future updates to it are done in the callback, under the above spinlock. (d) The above bitmap is used (instead of cpu_online_mask) while locking and unlocking the per-cpu locks. The callback takes the spinlock upon the CPU_UP_PREPARE event. So, if the br_write_lock-unlock sequence is in progress, the callback keeps spinning, thus preventing the CPU online operation till the lock-unlock sequence is complete. This takes care of requirement (3). The bitmap that we maintain remains unmodified throughout the lock-unlock sequence, since all updates to it are managed by the callback, which takes the same spinlock as the one taken by the lock code and released only by the unlock routine. Combining this with (d) above, satisfies requirement (2). Overall, since we use a spinlock (mentioned in (a)) to prevent CPU hotplug operations from racing with br_write_lock-unlock, requirement (1) is also taken care of. By the way, it is to be noted that a CPU offline operation can actually run in parallel with our lock-unlock sequence, because our callback doesn't react to notifications earlier than CPU_DEAD (in order to maintain our bitmap properly). And this means, since we use our own bitmap (which is stale, on purpose) during the lock-unlock sequence, we could end up unlocking the per-cpu lock of an offline CPU (because we had locked it earlier, when the CPU was online), in order to satisfy requirement (2). But this is harmless, though it looks a bit awkward. Debugged-by: Cong Meng <[email protected]> Signed-off-by: Srivatsa S. Bhat <[email protected]> Signed-off-by: Al Viro <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This reverts commit 7e76958.
The dwc_common_port library used by the dwc_otg includes bignumber and crypto functions which require 64x64 multiplication functions. Remove this dead code. Signed-off-by: Chris Boot <[email protected]>
This was added for the DWC OTG driver in commit d5ef856. As we've removed the dead code from that driver that depends on this, it is no longer required at all. Signed-off-by: Chris Boot <[email protected]>
Signed-off-by: Chris Boot <[email protected]>
Not sure what the original code was trying to do as it was completely wrong on many levels. This patch fixes the macro to return the correct physical and virtual addresses of the PL011 UART on the RPi. Note that you need to boot the compressed kernel (zImage) so that the UART is configured at boot, or your kernel will hang when it tries to access the UART. Signed-off-by: Chris Boot <[email protected]>
Signed-off-by: Chris Boot <[email protected]>
Signed-off-by: Chris Boot <[email protected]> Conflicts: arch/arm/Kconfig.debug arch/arm/mach-bcm2708/include/mach/memory.h
The calculated values somehow don't agree with the sched_clock code and we end up with warnings like: sched_clock: wrong multiply/shift: 2097152000>>21 vs calculated 4194304000>>22 sched_clock: fix multiply/shift to avoid scheduler hiccups So use the constant values much like arch/arm/mach-tegra/timer.c does. Signed-off-by: Chris Boot <[email protected]>
The additional FIFO might speed up transfers in some cases.
There are issues with both single block reads (missed completion) and writes (data loss in some cases!). Just don't do single block transfers anymore, and treat them like multiblock transfers. This adds a quirk for this and uses it.
sdhci-bcm2708 enhancements (possible fix for dataloss bug)
…status=0 may improve interrupt latency
The TIMER_PERIOD should be calculated using the timer interrupt frequenc...
…tg USB driver. Enable through /proc/dwc_sof/SOF_reduction" This reverts commit 85b7821.
Update Synopsys USB OTG driver to v2.94a and disable CRYPTOLIB. Third attempt
This checkin includes some debug, but its mainly trying to force transactions to start on frame .7 so that they complete correctly before the end of the frame.
Conflicts: drivers/usb/host/dwc_otg/dwc_otg_cil.c drivers/usb/host/dwc_otg/dwc_otg_hcd_intr.c
The bcm2708 SPI driver's bcm2708_process_transfer() was ignoring the per-transfer speed_hz value even when it was provided (it always just used the spi device's max_speed_hz value). Now, per-transfer speed_hz values are respected. Also added debug print to bcm2708_setup_state() to help keep an eye on the configured SPI parameters. Signed-off-by: Kamal Mostafa <[email protected]>
spi/spi-bcm2708: respect per-transfer SPI clock speed_hz value
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.