17 Jan, 2015

4 commits

  • Pull USB fixes from Greg KH:
    "Here is a bunch of USB fixes for 3.19-rc5.

    Most of these are gadget driver fixes, along with the xhci driver fix
    that we both reported having problems with, as well as some new device
    ids and other tiny fixes.

    All have been in linux-next with no problems"

    * tag 'usb-3.19-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (43 commits)
    usb: dwc3: gadget: Stop TRB preparation after limit is reached
    usb: dwc3: gadget: Fix TRB preparation during SG
    usb: phy: mv-usb: fix usb_phy build errors
    usb: serial: handle -ENODEV quietly in generic_submit_read_urb
    usb: serial: silence all non-critical read errors
    USB: console: fix potential use after free
    USB: console: fix uninitialised ldisc semaphore
    usb: gadget: udc: atmel: fix possible oops when unloading module
    usb: gadget: gadgetfs: fix an oops in ep_write()
    usb: phy: Fix deferred probing
    OHCI: add a quirk for ULi M5237 blocking on reset
    uas: Add US_FL_NO_ATA_1X for 2 more Seagate disk enclosures
    uas: Do not blacklist ASM1153 disk enclosures
    usb: gadget: udc: avoid dereference before NULL check in ep_queue
    usb: host: ehci-tegra: request deferred probe when failing to get phy
    uas: disable UAS on Apricorn SATA dongles
    uas: Add US_FL_NO_REPORT_OPCODES for JMicron JMS566 with usb-id 0bc2:a013
    uas: Add US_FL_NO_ATA_1X for Seagate devices with usb-id 0bc2:a013
    xhci: Add broken-streams quirk for Fresco Logic FL1000G xhci controllers
    USB: EHCI: adjust error return code
    ...

    Linus Torvalds
     
  • Pull arm64 fixes from Will Deacon:
    - Wire up compat_sys_execveat for compat (AArch32) tasks
    - Revert 421520ba9829, as this breaks our side of the boot protocol

    * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
    arm64: partially revert "ARM: 8167/1: extend the reserved memory for initrd to be page aligned"
    arm64: compat: wire up compat_sys_execveat

    Linus Torvalds
     
  • Pull NFS client bugfixes from Trond Myklebust:
    "Highlights include:

    - Stable fix for a NFSv3/lockd race
    - Fixes for several NFSv4.1 client id trunking bugs
    - Remove an incorrect test when checking for delegated opens"

    * tag 'nfs-for-3.19-2' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
    NFSv4: Remove incorrect check in can_open_delegated()
    NFS: Ignore transport protocol when detecting server trunking
    NFSv4/v4.1: Verify the client owner id during trunking detection
    NFSv4: Cache the NFSv4/v4.1 client owner_id in the struct nfs_client
    NFSv4.1: Fix client id trunking on Linux
    LOCKD: Fix a race when initialising nlmsvc_timeout

    Linus Torvalds
     
  • …it/rostedt/linux-trace

    Pull ftrace fixes from Steven Rostedt:
    "This holds a few fixes to the ftrace infrastructure as well as the
    mixture of function graph tracing and kprobes.

    When jprobes and function graph tracing is enabled at the same time it
    will crash the system:

    # modprobe jprobe_example
    # echo function_graph > /sys/kernel/debug/tracing/current_tracer

    After the first fork (jprobe_example probes it), the system will
    crash.

    This is due to the way jprobes copies the stack frame and does not do
    a normal function return. This messes up with the function graph
    tracing accounting which hijacks the return address from the stack and
    replaces it with a hook function. It saves the return addresses in a
    separate stack to put back the correct return address when done. But
    because the jprobe functions do not do a normal return, their stack
    addresses are not put back until the function they probe is called,
    which means that the probed function will get the return address of
    the jprobe handler instead of its own.

    The simple fix here was to disable function graph tracing while the
    jprobe handler is being called.

    While debugging this I found two minor bugs with the function graph
    tracing.

    The first was about the function graph tracer sharing its function
    hash with the function tracer (they both get filtered by the same
    input). The changing of the set_ftrace_filter would not sync the
    function recording records after a change if the function tracer was
    disabled but the function graph tracer was enabled. This was due to
    the update only checking one of the ops instead of the shared ops to
    see if they were enabled and should perform the sync. This caused the
    ftrace accounting to break and a ftrace_bug() would be triggered,
    disabling ftrace until a reboot.

    The second was that the check to update records only checked one of
    the filter hashes. It needs to test both the "filter" and "notrace"
    hashes. The "filter" hash determines what functions to trace where as
    the "notrace" hash determines what functions not to trace (trace all
    but these). Both hashes need to be passed to the update code to find
    out what change is being done during the update. This also broke the
    ftrace record accounting and triggered a ftrace_bug().

    This patch set also include two more fixes that were reported
    separately from the kprobe issue.

    One was that init_ftrace_syscalls() was called twice at boot up. This
    is not a major bug, but that call performed a rather large kmalloc
    (NR_syscalls * sizeof(*syscalls_metadata)). The second call made the
    first one a memory leak, and wastes memory.

    The other fix is a regression caused by an update in the v3.19 merge
    window. The moving to enable events early, moved the enabling before
    PID 1 was created. The syscall events require setting the
    TIF_SYSCALL_TRACEPOINT for all tasks. But for_each_process_thread()
    does not include the swapper task (PID 0), and ended up being a nop.

    A suggested fix was to add the init_task() to have its flag set, but I
    didn't really want to mess with PID 0 for this minor bug. Instead I
    disable and re-enable events again at early_initcall() where it use to
    be enabled. This also handles any other event that might have its own
    reg function that could break at early boot up"

    * tag 'trace-fixes-v3.19-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
    tracing: Fix enabling of syscall events on the command line
    tracing: Remove extra call to init_ftrace_syscalls()
    ftrace/jprobes/x86: Fix conflict between jprobes and function graph tracing
    ftrace: Check both notrace and filter for old hash
    ftrace: Fix updating of filters for shared global_ops filters

    Linus Torvalds
     

16 Jan, 2015

6 commits


15 Jan, 2015

25 commits

  • Commit 5f893b2639b2 "tracing: Move enabling tracepoints to just after
    rcu_init()" broke the enabling of system call events from the command
    line. The reason was that the enabling of command line trace events
    was moved before PID 1 started, and the syscall tracepoints require
    that all tasks have the TIF_SYSCALL_TRACEPOINT flag set. But the
    swapper task (pid 0) is not part of that. Since the swapper task is the
    only task that is running at this early in boot, no task gets the
    flag set, and the tracepoint never gets reached.

    Instead of setting the swapper task flag (there should be no reason to
    do that), re-enabled trace events again after the init thread (PID 1)
    has been started. It requires disabling all command line events and
    re-enabling them, as just enabling them again will not reset the logic
    to set the TIF_SYSCALL_TRACEPOINT flag, as the syscall tracepoint will
    be fooled into thinking that it was already set, and wont try setting
    it again. For this reason, we must first disable it and re-enable it.

    Link: http://lkml.kernel.org/r/1421188517-18312-1-git-send-email-mpe@ellerman.id.au
    Link: http://lkml.kernel.org/r/20150115040506.216066449@goodmis.org

    Reported-by: Michael Ellerman
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • trace_init() calls init_ftrace_syscalls() and then calls trace_event_init()
    which also calls init_ftrace_syscalls(). It makes more sense to only
    call it from trace_event_init().

    Calling it twice wastes memory, as it allocates the syscall events twice,
    and loses the first copy of it.

    Link: http://lkml.kernel.org/r/54AF53BD.5070303@huawei.com
    Link: http://lkml.kernel.org/r/20150115040505.930398632@goodmis.org

    Reported-by: Wang Nan
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • If the function graph tracer traces a jprobe callback, the system will
    crash. This can easily be demonstrated by compiling the jprobe
    sample module that is in the kernel tree, loading it and running the
    function graph tracer.

    # modprobe jprobe_example.ko
    # echo function_graph > /sys/kernel/debug/tracing/current_tracer
    # ls

    The first two commands end up in a nice crash after the first fork.
    (do_fork has a jprobe attached to it, so "ls" just triggers that fork)

    The problem is caused by the jprobe_return() that all jprobe callbacks
    must end with. The way jprobes works is that the function a jprobe
    is attached to has a breakpoint placed at the start of it (or it uses
    ftrace if fentry is supported). The breakpoint handler (or ftrace callback)
    will copy the stack frame and change the ip address to return to the
    jprobe handler instead of the function. The jprobe handler must end
    with jprobe_return() which swaps the stack and does an int3 (breakpoint).
    This breakpoint handler will then put back the saved stack frame,
    simulate the instruction at the beginning of the function it added
    a breakpoint to, and then continue on.

    For function tracing to work, it hijakes the return address from the
    stack frame, and replaces it with a hook function that will trace
    the end of the call. This hook function will restore the return
    address of the function call.

    If the function tracer traces the jprobe handler, the hook function
    for that handler will not be called, and its saved return address
    will be used for the next function. This will result in a kernel crash.

    To solve this, pause function tracing before the jprobe handler is called
    and unpause it before it returns back to the function it probed.

    Some other updates:

    Used a variable "saved_sp" to hold kcb->jprobe_saved_sp. This makes the
    code look a bit cleaner and easier to understand (various tries to fix
    this bug required this change).

    Note, if fentry is being used, jprobes will change the ip address before
    the function graph tracer runs and it will not be able to trace the
    function that the jprobe is probing.

    Link: http://lkml.kernel.org/r/20150114154329.552437962@goodmis.org

    Cc: stable@vger.kernel.org # 2.6.30+
    Acked-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • Using just the filter for checking for trampolines or regs is not enough
    when updating the code against the records that represent all functions.
    Both the filter hash and the notrace hash need to be checked.

    To trigger this bug (using trace-cmd and perf):

    # perf probe -a do_fork
    # trace-cmd start -B foo -e probe
    # trace-cmd record -p function_graph -n do_fork sleep 1

    The trace-cmd record at the end clears the filter before it disables
    function_graph tracing and then that causes the accounting of the
    ftrace function records to become incorrect and causes ftrace to bug.

    Link: http://lkml.kernel.org/r/20150114154329.358378039@goodmis.org

    Cc: stable@vger.kernel.org
    [ still need to switch old_hash_ops to old_ops_hash ]
    Reviewed-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • As the set_ftrace_filter affects both the function tracer as well as the
    function graph tracer, the ops that represent each have a shared
    ftrace_ops_hash structure. This allows both to be updated when the filter
    files are updated.

    But if function graph is enabled and the global_ops (function tracing) ops
    is not, then it is possible that the filter could be changed without the
    update happening for the function graph ops. This will cause the changes
    to not take place and may even cause a ftrace_bug to occur as it could mess
    with the trampoline accounting.

    The solution is to check if the ops uses the shared global_ops filter and
    if the ops itself is not enabled, to check if there's another ops that is
    enabled and also shares the global_ops filter. In that case, the
    modification still needs to be executed.

    Link: http://lkml.kernel.org/r/20150114154329.055980438@goodmis.org

    Cc: stable@vger.kernel.org # 3.17+
    Reviewed-by: Masami Hiramatsu
    Signed-off-by: Steven Rostedt

    Steven Rostedt (Red Hat)
     
  • Pull thermal fixes from Zhang Rui:
    "Specifics:

    - bogus type qualifier fix in OF thermal code.
    - Minor fixes on imx and rcar thermal drivers.
    - Update TI SoC thermal maintainer entry.
    - Updated documentation of OF cpufreq cooling register"

    * 'thermal-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
    thermal: rcar: Spelling/grammar: s/drier use .../driver uses ...s/
    thermal: rcar: change type of ctemp in rcar_thermal_update_temp()
    thermal: rcar: fix ENR register value
    Documentation: thermal: document of_cpufreq_cooling_register()
    Thermal: imx: add clk disable/enable for suspend/resume
    MAINTAINERS: update ti-soc-thermal status
    MAINTAINERS: Add linux-omap to list of reviewers for TI Thermal
    thermal: of: Remove bogus type qualifier for of_thermal_get_trip_points()

    Linus Torvalds
     
  • …/balbi/usb into usb-linus

    Felipe writes:

    usb: fixes for v3.19-rc6

    The final set of fixes for v3.19. Two of the fixes are
    related to dwc3 scatter/gather implementation when we have
    more requests queued than available TRBs, while the other
    is a build fix for mv-usb PHY.

    Signed-off-by: Felipe Balbi <balbi@ti.com>

    Greg Kroah-Hartman
     
  • …/johan/usb-serial into usb-linus

    Johan writes:

    USB-serial fixes for v3.18-rc5

    Here are a few fixes for reported problems including a possible
    null-deref on probe with keyspan, a misbehaving modem, and a couple of
    issues with the USB console.

    Some new device IDs are also added.

    Signed-off-by: Johan Hovold <johan@kernel.org>

    Greg Kroah-Hartman
     
  • Pull networking fixes from David Miller:

    1) Don't use uninitialized data in IPVS, from Dan Carpenter.

    2) conntrack race fixes from Pablo Neira Ayuso.

    3) Fix TX hangs with i40e, from Jesse Brandeburg.

    4) Fix budget return from poll calls in dnet and alx, from Eric
    Dumazet.

    5) Fix bugus "if (unlikely(x) < 0)" test in AF_PACKET, from Christoph
    Jaeger.

    6) Fix bug introduced by conversion to list_head in TIPC retransmit
    code, from Jon Paul Maloy.

    7) Don't use GFP_NOIO under spinlock in USB kaweth driver, from Alexey
    Khoroshilov.

    8) Fix bridge build with INET disabled, from Arnd Bergmann.

    9) Fix netlink array overrun for PROBE attributes in openvswitch, from
    Thomas Graf.

    10) Don't hold spinlock across synchronize_irq() in tg3 driver, from
    Prashant Sreedharan.

    * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (44 commits)
    tg3: Release tp->lock before invoking synchronize_irq()
    tg3: tg3_reset_task() needs to use rtnl_lock to synchronize
    tg3: tg3_timer() should grab tp->lock before checking for tp->irq_sync
    team: avoid possible underflow of count_pending value for notify_peers and mcast_rejoin
    openvswitch: packet messages need their own probe attribtue
    i40e: adds FCoE configure option
    cxgb4vf: Fix queue allocation for 40G adapter
    netdevice: Add missing parentheses in macro
    bridge: only provide proxy ARP when CONFIG_INET is enabled
    neighbour: fix base_reachable_time(_ms) not effective immediatly when changed
    net: fec: fix MDIO bus assignement for dual fec SoC's
    xen-netfront: use different locks for Rx and Tx stats
    drivers: net: cpsw: fix multicast flush in dual emac mode
    cxgb4vf: Initialize mdio_addr before using it
    net: Corrected the comment describing the ndo operations to reflect the actual prototype for couple of operations
    usb/kaweth: use GFP_ATOMIC under spin_lock in usb_start_wait_urb()
    MAINTAINERS: add me as ibmveth maintainer
    tipc: fix bug in broadcast retransmit code
    update ip-sysctl.txt documentation (v2)
    net/at91_ether: prepare and unprepare clock
    ...

    Linus Torvalds
     
  • Prashant Sreedharan says:

    ====================
    tg3: synchronize_irq() should be called without taking locks

    v2: Added Reported-by, Tested-by fields and reference to the thread that
    reported the problem

    This series addresses the problem reported by Peter Hurley in mail thread
    https://lkml.org/lkml/2015/1/12/1082
    ====================

    Signed-off-by: David S. Miller

    David S. Miller
     
  • synchronize_irq() can sleep waiting, for pending IRQ handlers so driver
    should release the tp->lock spin lock before invoking synchronize_irq()

    Reported-by: Peter Hurley
    Tested-by: Peter Hurley
    Signed-off-by: Prashant Sreedharan
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller

    Prashant Sreedharan
     
  • Currently tg3_reset_task() uses only tp->lock for synchronizing with code
    paths like tg3_open() etc. But since tp->lock is released before doing
    synchronize_irq(), rtnl_lock should be taken in tg3_reset_task() to
    synchronize it with other code paths.

    Reported-by: Peter Hurley
    Tested-by: Peter Hurley
    Signed-off-by: Prashant Sreedharan
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller

    Prashant Sreedharan
     
  • This is to avoid the race between tg3_timer() and the execution paths
    which does not invoke tg3_timer_stop() and releases tp->lock before
    calling synchronize_irq()

    Reported-by: Peter Hurley
    Tested-by: Peter Hurley
    Signed-off-by: Prashant Sreedharan
    Signed-off-by: Michael Chan
    Signed-off-by: David S. Miller

    Prashant Sreedharan
     
  • Pull kvm fixes from Paolo Bonzini:
    "Two bugfixes for arm64. I will have another pull request next week,
    but otherwise things are calm"

    * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
    arm64: KVM: Fix HCR setting for 32bit guests
    arm64: KVM: Fix TLB invalidation by IPA/VMID

    Linus Torvalds
     
  • This patch is fixing a race condition that may cause setting
    count_pending to -1, which results in unwanted big bulk of arp messages
    (in case of "notify peers").

    Consider following scenario:

    count_pending == 2
    CPU0 CPU1
    team_notify_peers_work
    atomic_dec_and_test (dec count_pending to 1)
    schedule_delayed_work
    team_notify_peers
    atomic_add (adding 1 to count_pending)
    team_notify_peers_work
    atomic_dec_and_test (dec count_pending to 1)
    schedule_delayed_work
    team_notify_peers_work
    atomic_dec_and_test (dec count_pending to 0)
    schedule_delayed_work
    team_notify_peers_work
    atomic_dec_and_test (dec count_pending to -1)

    Fix this race by using atomic_dec_if_positive - that will prevent
    count_pending running under 0.

    Fixes: fc423ff00df3a1955441 ("team: add peer notification")
    Fixes: 492b200efdd20b8fcfd ("team: add support for sending multicast rejoins")
    Signed-off-by: Jiri Pirko
    Signed-off-by: Jiri Benc
    Signed-off-by: David S. Miller

    Jiri Pirko
     
  • Pull s390 fixes from Martin Schwidefsky:
    "Two small performance tweaks, the plumbing for the execveat system
    call and a couple of bug fixes"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
    s390/uprobes: fix user space PER events
    s390/bpf: Fix JMP_JGE_X (A > X) and JMP_JGT_X (A >= X)
    s390/bpf: Fix ALU_NEG (A = -A)
    s390/mm: avoid using pmd_to_page for !USE_SPLIT_PMD_PTLOCKS
    s390/timex: fix get_tod_clock_ext() inline assembly
    s390: wire up execveat syscall
    s390/kernel: use stnsm 255 instead of stosm 0
    s390/vtime: Get rid of redundant WARN_ON
    s390/zcrypt: kernel oops at insmod of the z90crypt device driver

    Linus Torvalds
     
  • User space is currently sending a OVS_FLOW_ATTR_PROBE for both flow
    and packet messages. This leads to an out-of-bounds access in
    ovs_packet_cmd_execute() because OVS_FLOW_ATTR_PROBE >
    OVS_PACKET_ATTR_MAX.

    Introduce a new OVS_PACKET_ATTR_PROBE with the same numeric value
    as OVS_FLOW_ATTR_PROBE to grow the range of accepted packet attributes
    while maintaining to be binary compatible with existing OVS binaries.

    Fixes: 05da589 ("openvswitch: Add support for OVS_FLOW_ATTR_PROBE.")
    Reported-by: Sander Eikelenboom
    Tracked-down-by: Florian Westphal
    Signed-off-by: Thomas Graf
    Reviewed-by: Jesse Gross
    Acked-by: Pravin B Shelar
    Signed-off-by: David S. Miller

    Thomas Graf
     
  • Adds FCoE config option I40E_FCOE, so that FCoE can be enabled
    as needed but otherwise have it disabled by default.

    This also eliminate multiple FCoE config checks, instead now just
    one config check for CONFIG_I40E_FCOE.

    The I40E FCoE was added with 3.17 kernel and therefore this patch
    shall be applied to stable 3.17 kernel also.

    CC:
    Signed-off-by: Vasu Dev
    Tested-by: Jim Young
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller

    Vasu Dev
     
  • Signed-off-by: Hariprasad Shenai
    Signed-off-by: David S. Miller

    Hariprasad Shenai
     
  • Pull file locking fix from Jeff Layton:
    "Just a simple bugfix for a regression that I introduced into v3.18
    with the internal lease API overhaul -- mea culpa. Kudos to Linda and
    Neil for tracking this down and fixing it"

    * tag 'locks-v3.19-1' of git://git.samba.org/jlayton/linux:
    locks: fix NULL-deref in generic_delete_lease

    Linus Torvalds
     
  • For example, one could conceivably call
    for_each_netdev_in_bond_rcu(condition ? bond1 : bond2, slave)
    and get an unexpected result.

    Signed-off-by: Benjamin Poirier
    Signed-off-by: David S. Miller

    Benjamin Poirier
     
  • Pull block layer fixes from Jens Axboe:
    "The major part is an update to the NVMe driver, fixing various issues
    around surprise removal and hung controllers. Most of that is from
    Keith, and parts are simple blk-mq fixes or exports/additions of minor
    functions to aid this effort, and parts are changes directly to the
    NVMe driver.

    Apart from the above, this contains:

    - Small blk-mq change from me, killing an unused member of the
    hardware queue structure.

    - Small fix from Ming Lei, fixing up a few drivers that didn't
    properly check for ERR_PTR() returns from blk_mq_init_queue()"

    * 'for-linus' of git://git.kernel.dk/linux-block:
    NVMe: Fix locking on abort handling
    NVMe: Start and stop h/w queues on reset
    NVMe: Command abort handling fixes
    NVMe: Admin queue removal handling
    NVMe: Reference count admin queue usage
    NVMe: Start all requests
    blk-mq: End unstarted requests on a dying queue
    blk-mq: Allow requests to never expire
    blk-mq: Add helper to abort requeued requests
    blk-mq: Let drivers cancel requeue_work
    blk-mq: Export if requests were started
    blk-mq: Wake tasks entering queue on dying
    blk-mq: get rid of ->cmd_size in the hardware queue
    block: fix checking return value of blk_mq_init_queue
    block: wake up waiters when a queue is marked dying
    NVMe: Fix double free irq
    blk-mq: Export freeze/unfreeze functions
    blk-mq: Exit queue on alloc failure

    Linus Torvalds
     
  • When IPV4 support is disabled, we cannot call arp_send from
    the bridge code, which would result in a kernel link error:

    net/built-in.o: In function `br_handle_frame_finish':
    :(.text+0x59914): undefined reference to `arp_send'
    :(.text+0x59a50): undefined reference to `arp_tbl'

    This makes the newly added proxy ARP support in the bridge
    code depend on the CONFIG_INET symbol and lets the compiler
    optimize the code out to avoid the link error.

    Signed-off-by: Arnd Bergmann
    Fixes: 958501163ddd ("bridge: Add support for IEEE 802.11 Proxy ARP")
    Cc: Kyeyoon Park
    Signed-off-by: David S. Miller

    Arnd Bergmann
     
  • DWC3 gadget sets up a pool of 32 TRBs for each EP during initialization. This
    means, the max TRBs that can be submitted for an EP is fixed to 32. Since the
    request queue for an EP is a linked list, any number of requests can be queued
    to it by the gadget layer. However, the dwc3 driver must not submit TRBs more
    than the pool it has created for. This limit wasn't respected when SG was used
    resulting in submitting more than the max TRBs, eventually leading to
    non-transfer of the TRBs submitted over the max limit.

    Root cause:
    When SG is used, there are two loops iterating to prepare TRBs:
    - Outer loop over the request_list
    - Inner loop over the SG list
    The code was missing break to get out of the outer loop.

    Fixes: eeb720fb21d6 (usb: dwc3: gadget: add support for SG lists)
    Cc: # v3.9+
    Signed-off-by: Amit Virdi
    Signed-off-by: Felipe Balbi

    Amit Virdi
     
  • When scatter gather (SG) is used, multiple TRBs are prepared from one DWC3
    request (dwc3_request). So while preparing TRBs, the 'last' flag should be set
    only when it is the last TRB being prepared from the last dwc3_request entry.

    The current implementation uses list_is_last to check if the dwc3_request is the
    last entry from the request_list. However, list_is_last returns false for the
    last entry too. This is because, while preparing the first TRB from a request,
    the function dwc3_prepare_one_trb modifies the request's next and prev pointers
    while moving the URB to req_queued. Hence, list_is_last always returns false no
    matter what.

    The correct way is not to access the modified pointers of dwc3_request but to
    use list_empty macro instead.

    Fixes: e5ba5ec833aa (usb: dwc3: gadget: fix scatter gather implementation)
    Signed-off-by: Amit Virdi
    Cc: # v3.9+
    Signed-off-by: Felipe Balbi

    Amit Virdi
     

14 Jan, 2015

5 commits

  • Host controllers lacking the required internal vmmc regulator may still
    follow the spec with regard to the LSB of SDHCI_POWER_CONTROL. Set the
    SDHCI_POWER_ON bit when vmmc is enabled to encourage the controller to
    to drive CMD, DAT, SDCLK.

    This fixes a regression observed on some Qualcomm and Nvidia boards
    caused by 5222161 mmc: sdhci: Improve external VDD regulator support.

    Fixes: 52221610dd84 (mmc: sdhci: Improve external VDD regulator support)
    Signed-off-by: Tim Kryger
    Tested-by: Bjorn Andersson
    Signed-off-by: Ulf Hansson

    Tim Kryger
     
  • …inux-soc-thermal into thermal-soc

    Zhang Rui
     
  • When setting base_reachable_time or base_reachable_time_ms on a
    specific interface through sysctl or netlink, the reachable_time
    value is not updated.

    This means that neighbour entries will continue to be updated using the
    old value until it is recomputed in neigh_period_work (which
    recomputes the value every 300*HZ).
    On systems with HZ equal to 1000 for instance, it means 5mins before
    the change is effective.

    This patch changes this behavior by recomputing reachable_time after
    each set on base_reachable_time or base_reachable_time_ms.
    The new value will become effective the next time the neighbour's timer
    is triggered.

    Changes are made in two places: the netlink code for set and the sysctl
    handling code. For sysctl, I use a proc_handler. The ipv6 network
    code does provide its own handler but it already refreshes
    reachable_time correctly so it's not an issue.
    Any other user of neighbour which provide its own handlers must
    refresh reachable_time.

    Signed-off-by: Jean-Francois Remy
    Signed-off-by: David S. Miller

    Jean-Francois Remy
     
  • On i.MX28, the MDIO bus is shared between the two FEC instances.
    The driver makes sure that the second FEC uses the MDIO bus of the
    first FEC. This is done conditionally if FEC_QUIRK_ENET_MAC is set.
    However, in newer designs, such as Vybrid or i.MX6SX, each FEC MAC
    has its own MDIO bus. Simply removing the quirk FEC_QUIRK_ENET_MAC
    is not an option since other logic, triggered by this quirk, is
    still needed.

    Furthermore, there are board designs which use the same MDIO bus
    for both PHY's even though the second bus would be available on the
    SoC side. Such layout are popular since it saves pins on SoC side.
    Due to the above quirk, those boards currently do work fine. The
    boards in the mainline tree with such a layout are:
    - Freescale Vybrid Tower with TWR-SER2 (vf610-twr.dts)
    - Freescale i.MX6 SoloX SDB Board (imx6sx-sdb.dts)

    This patch adds a new quirk FEC_QUIRK_SINGLE_MDIO for i.MX28, which
    makes sure that the MDIO bus of the first FEC is used in any case.

    However, the boards above do have a SoC with a MDIO bus for each FEC
    instance. But the PHY's are not connected in a 1:1 configuration. A
    proper device tree description is needed to allow the driver to
    figure out where to find its PHY. This patch fixes that shortcoming
    by adding a MDIO bus child node to the first FEC instance, along
    with the two PHY's on that bus, and making use of the phy-handle
    property to add a reference to the PHY's.

    Acked-by: Sascha Hauer
    Signed-off-by: Stefan Agner
    Signed-off-by: David S. Miller

    Stefan Agner
     
  • …git/cooloney/linux-leds

    Pull LED fix from Bryan Wu.

    * 'leds-fixes-for-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds:
    leds: netxbig: fix oops at probe time

    Linus Torvalds