1. 16 Jul, 2014 7 commits
  2. 15 Jul, 2014 9 commits
    • Niu Yawei's avatar
      quota: missing lock in dqcache_shrink_scan() · d68aab6b
      Niu Yawei authored
      Commit 1ab6c499 (fs: convert fs shrinkers to new scan/count API)
      accidentally removed locking from quota shrinker. Fix it -
      dqcache_shrink_scan() should use dq_list_lock to protect the
      scan on free_dquots list.
      
      CC: stable@vger.kernel.org
      Fixes: 1ab6c499Signed-off-by: default avatarNiu Yawei <yawei.niu@intel.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      d68aab6b
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse · 0b632204
      Linus Torvalds authored
      Pull fuse fixes from Miklos Szeredi:
       "This contains miscellaneous fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
        fuse: replace count*size kzalloc by kcalloc
        fuse: release temporary page if fuse_writepage_locked() failed
        fuse: restructure ->rename2()
        fuse: avoid scheduling while atomic
        fuse: handle large user and group ID
        fuse: inode: drop cast
        fuse: ignore entry-timeout on LOOKUP_REVAL
        fuse: timeout comparison fix
      0b632204
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 5615f9f8
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Bluetooth pairing fixes from Johan Hedberg.
      
       2) ieee80211_send_auth() doesn't allocate enough tail room for the SKB,
          from Max Stepanov.
      
       3) New iwlwifi chip IDs, from Oren Givon.
      
       4) bnx2x driver reads wrong PCI config space MSI register, from Yijing
          Wang.
      
       5) IPV6 MLD Query validation isn't strong enough, from Hangbin Liu.
      
       6) Fix double SKB free in openvswitch, from Andy Zhou.
      
       7) Fix sk_dst_set() being racey with UDP sockets, leading to strange
          crashes, from Eric Dumazet.
      
       8) Interpret the NAPI budget correctly in the new systemport driver,
          from Florian Fainelli.
      
       9) VLAN code frees percpu stats in the wrong place, leading to crashes
          in the get stats handler.  From Eric Dumazet.
      
      10) TCP sockets doing a repair can crash with a divide by zero, because
          we invoke tcp_push() with an MSS value of zero.  Just skip that part
          of the sendmsg paths in repair mode.  From Christoph Paasch.
      
      11) IRQ affinity bug fixes in mlx4 driver from Amir Vadai.
      
      12) Don't ignore path MTU icmp messages with a zero mtu, machines out
          there still spit them out, and all of our per-protocol handlers for
          PMTU can cope with it just fine.  From Edward Allcutt.
      
      13) Some NETDEV_CHANGE notifier invocations were not passing in the
          correct kind of cookie as the argument, from Loic Prylli.
      
      14) Fix crashes in long multicast/broadcast reassembly, from Jon Paul
          Maloy.
      
      15) ip_tunnel_lookup() doesn't interpret wildcard keys correctly, fix
          from Dmitry Popov.
      
      16) Fix skb->sk assigned without taking a reference to 'sk' in
          appletalk, from Andrey Utkin.
      
      17) Fix some info leaks in ULP event signalling to userspace in SCTP,
          from Daniel Borkmann.
      
      18) Fix deadlocks in HSO driver, from Olivier Sobrie.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (93 commits)
        hso: fix deadlock when receiving bursts of data
        hso: remove unused workqueue
        net: ppp: don't call sk_chk_filter twice
        mlx4: mark napi id for gro_skb
        bonding: fix ad_select module param check
        net: pppoe: use correct channel MTU when using Multilink PPP
        neigh: sysctl - simplify address calculation of gc_* variables
        net: sctp: fix information leaks in ulpevent layer
        MAINTAINERS: update r8169 maintainer
        net: bcmgenet: fix RGMII_MODE_EN bit
        tipc: clear 'next'-pointer of message fragments before reassembly
        r8152: fix r8152_csum_workaround function
        be2net: set EQ DB clear-intr bit in be_open()
        GRE: enable offloads for GRE
        farsync: fix invalid memory accesses in fst_add_one() and fst_init_card()
        igb: do a reset on SR-IOV re-init if device is down
        igb: Workaround for i210 Errata 25: Slow System Clock
        usbnet: smsc95xx: add reset_resume function with reset operation
        dp83640: Always decode received status frames
        r8169: disable L23
        ...
      5615f9f8
    • Takashi Iwai's avatar
      ALSA: hda - Fix broken PM due to incomplete i915 initialization · 4da63c6f
      Takashi Iwai authored
      When the initialization of Intel HDMI controller fails due to missing
      i915 kernel symbols (e.g. HD-audio is built in while i915 is module),
      the driver discontinues the probe.  However, since the probe was done
      asynchronously, the driver object still remains, thus the relevant PM
      ops are still called at suspend/resume. This results in the bad access
      to the incomplete audio card object, eventually leads to Oops or stall
      at PM.
      
      This patch adds the missing checks of chip->init_failed flag at each
      PM callback in order to fix the problem above.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79561
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4da63c6f
    • Olivier Sobrie's avatar
      hso: fix deadlock when receiving bursts of data · 8f9818af
      Olivier Sobrie authored
      When the module sends bursts of data, sometimes a deadlock happens in
      the hso driver when the tty buffer doesn't get the chance to be flushed
      quickly enough.
      
      Remove the endless while loop in function put_rxbuf_data() which is
      called by the urb completion handler.
      If there isn't enough room in the tty buffer, discards all the data
      received in the URB.
      
      Cc: David Miller <davem@davemloft.net>
      Cc: David Laight <David.Laight@ACULAB.COM>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Dan Williams <dcbw@redhat.com>
      Cc: Jan Dumon <j.dumon@option.com>
      Signed-off-by: default avatarOlivier Sobrie <olivier@sobrie.be>
      Acked-by: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f9818af
    • Olivier Sobrie's avatar
      hso: remove unused workqueue · 5c763edf
      Olivier Sobrie authored
      The workqueue "retry_unthrottle_workqueue" is not scheduled anywhere
      in the code. So, remove it.
      Signed-off-by: default avatarOlivier Sobrie <olivier@sobrie.be>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5c763edf
    • Linus Torvalds's avatar
      Merge tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394 · 1b81e881
      Linus Torvalds authored
      Pull firewire fix from Stefan Richter:
       "The 1394 drivers cannot and are not supposed to be built on platforms
        which don't provide the DMA mapping API (regression since v3.16-rc1
        with CONFIG_COMPILE_TEST=y on some architectures)"
      
      * tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
        firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA
      1b81e881
    • Linus Torvalds's avatar
      Merge git://git.kvack.org/~bcrl/aio-fixes · 8ec8ba8e
      Linus Torvalds authored
      Pull another aio fix from Ben LaHaise:
       "put_reqs_available() can now be called from within irq context, which
        means that it (and its sibling function get_reqs_available()) now need
        to be irq-safe, not just preempt-safe"
      
      * git://git.kvack.org/~bcrl/aio-fixes:
        aio: protect reqs_available updates from changes in interrupt handlers
      8ec8ba8e
    • Sasha Levin's avatar
      net/l2tp: don't fall back on UDP [get|set]sockopt · 3cf521f7
      Sasha Levin authored
      The l2tp [get|set]sockopt() code has fallen back to the UDP functions
      for socket option levels != SOL_PPPOL2TP since day one, but that has
      never actually worked, since the l2tp socket isn't an inet socket.
      
      As David Miller points out:
      
        "If we wanted this to work, it'd have to look up the tunnel and then
         use tunnel->sk, but I wonder how useful that would be"
      
      Since this can never have worked so nobody could possibly have depended
      on that functionality, just remove the broken code and return -EINVAL.
      Reported-by: default avatarSasha Levin <sasha.levin@oracle.com>
      Acked-by: default avatarJames Chapman <jchapman@katalix.com>
      Acked-by: default avatarDavid Miller <davem@davemloft.net>
      Cc: Phil Turnbull <phil.turnbull@oracle.com>
      Cc: Vegard Nossum <vegard.nossum@oracle.com>
      Cc: Willy Tarreau <w@1wt.eu>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3cf521f7
  3. 14 Jul, 2014 14 commits
    • Christoph Schulz's avatar
      net: ppp: don't call sk_chk_filter twice · 3916a319
      Christoph Schulz authored
      Commit 568f194e ("net: ppp: use
      sk_unattached_filter api") causes sk_chk_filter() to be called twice when
      setting a PPP pass or active filter. This applies to both the generic PPP
      subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
      subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
      within get_filter(). The second one is through the call chain
      
        ppp_ioctl() or isdn_ppp_ioctl()
        --> sk_unattached_filter_create()
            --> __sk_prepare_filter()
                --> sk_chk_filter()
      
      The first call from within get_filter() should be deleted as get_filter() is
      called just before calling sk_unattached_filter_create() later on, which
      eventually calls sk_chk_filter() anyway.
      
      For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
      in that branch, sk_chk_filter() may replace filter codes by other codes which
      are not recognized when executing sk_chk_filter() a second time. So with
      3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
      EINVAL (this depends on the filter codes found in the filter to be set, but
      because the replacement is done for frequently used codes, this is almost
      always the case). The net effect is that setting pass and/or active PPP filters
      does not work anymore, since sk_unattached_filter_create() always returns
      EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
      was originally sane or not.
      Signed-off-by: default avatarChristoph Schulz <develop@kristov.de>
      Acked-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3916a319
    • Jason Wang's avatar
      mlx4: mark napi id for gro_skb · 32b333fe
      Jason Wang authored
      Napi id was not marked for gro_skb, this will lead rx busy loop won't
      work correctly since they stack never try to call low latency receive
      method because of a zero socket napi id. Fix this by marking napi id
      for gro_skb.
      
      The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
      (from 20531.68 to 30610.88).
      
      Cc: Amir Vadai <amirv@mellanox.com>
      Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32b333fe
    • Nikolay Aleksandrov's avatar
      bonding: fix ad_select module param check · 548d28bd
      Nikolay Aleksandrov authored
      Obvious copy/paste error when I converted the ad_select to the new
      option API. "lacp_rate" there should be "ad_select" so we can get the
      proper value.
      
      CC: Jay Vosburgh <j.vosburgh@gmail.com>
      CC: Veaceslav Falico <vfalico@gmail.com>
      CC: Andy Gospodarek <andy@greyhouse.net>
      CC: David S. Miller <davem@davemloft.net>
      
      Fixes: 9e5f5eeb ("bonding: convert ad_select to use the new option
      API")
      Reported-by: default avatarKarim Scheik <karim.scheik@prisma-solutions.at>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      548d28bd
    • Christoph Schulz's avatar
      net: pppoe: use correct channel MTU when using Multilink PPP · a8a3e41c
      Christoph Schulz authored
      The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
      ppp_generic module) tries to determine how big a fragment might be. According
      to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
      corresponding comment and code in ppp_mp_explode():
      
      		/*
      		 * hdrlen includes the 2-byte PPP protocol field, but the
      		 * MTU counts only the payload excluding the protocol field.
      		 * (RFC1661 Section 2)
      		 */
      		mtu = pch->chan->mtu - (hdrlen - 2);
      
      However, the pppoe module *does* include the PPP protocol field in the channel
      MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
      certain circumstances (one byte if PPP protocol compression is used, two
      otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
      module has to subtract two bytes from the channel MTU. This error only
      manifests itself when using Multilink PPP, as otherwise the channel MTU is not
      used anywhere.
      
      In the following, I will describe how to reproduce this bug. We configure two
      pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
      a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
      computed by adding the two link MTUs and subtracting the MP header twice, which
      is 4 bytes long.) The necessary pppd statements on both sides are "multilink
      mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
      rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
      side, we additionally need to start two pppoe-server instances to be able to
      establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
      of the PPP network interface to the MRRU (2976) on both sides of the connection
      in order to make use of the higher bandwidth. (If we didn't do that, IP
      fragmentation would kick in, which we want to avoid.)
      
      Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
      server over the PPP link. This results in the following network packet:
      
         2948 (echo payload)
       +    8 (ICMPv4 header)
       +   20 (IPv4 header)
      ---------------------
         2976 (PPP payload)
      
      These 2976 bytes do not exceed the MTU of the PPP network interface, so the
      IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
      prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
      than the negotiated MRRU. So this packet would have to be divided in three
      fragments. But this does not happen as each link MTU is assumed to be two bytes
      larger. So this packet is diveded into two fragments only, one of size 1489 and
      one of size 1488. Now we have for that bigger fragment:
      
         1489 (PPP payload)
       +    4 (MP header)
       +    2 (PPP protocol field for the MP payload (0x3d))
       +    6 (PPPoE header)
      --------------------------
         1501 (Ethernet payload)
      
      This packet exceeds the link MTU and is discarded.
      
      If one configures the link MTU on the client side to 1501, one can see the
      discarded Ethernet frames with tcpdump running on the client. A
      
      ping -s 2948 -c 1 192.168.15.254
      
      leads to the smaller fragment that is correctly received on the server side:
      
      (tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [end], length 1492
      
      and to the bigger fragment that is not received on the server side:
      
      (tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1515: PPPoE  [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
        Flags [begin], length 1493
      
      With the patch below, we correctly obtain three fragments:
      
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [begin], length 1492
      52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
        length 1514: PPPoE  [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
        Flags [none], length 1492
      52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
        length 27: PPPoE  [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
        Flags [end], length 5
      
      And the ICMPv4 echo request is successfully received at the server side:
      
      IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
        length 2976)
          192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
            length 2956
      
      The bug was introduced in commit c9aa6895
      ("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
      to 3.10 upwards but the fix can be applied (with minor modifications) to
      kernels as old as 2.6.32.
      Signed-off-by: default avatarChristoph Schulz <develop@kristov.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8a3e41c
    • Mathias Krause's avatar
      neigh: sysctl - simplify address calculation of gc_* variables · 9ecf07a1
      Mathias Krause authored
      The code in neigh_sysctl_register() relies on a specific layout of
      struct neigh_table, namely that the 'gc_*' variables are directly
      following the 'parms' member in a specific order. The code, though,
      expresses this in the most ugly way.
      
      Get rid of the ugly casts and use the 'tbl' pointer to get a handle to
      the table. This way we can refer to the 'gc_*' variables directly.
      
      Similarly seen in the grsecurity patch, written by Brad Spengler.
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Cc: Brad Spengler <spender@grsecurity.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ecf07a1
    • Daniel Borkmann's avatar
      net: sctp: fix information leaks in ulpevent layer · 8f2e5ae4
      Daniel Borkmann authored
      While working on some other SCTP code, I noticed that some
      structures shared with user space are leaking uninitialized
      stack or heap buffer. In particular, struct sctp_sndrcvinfo
      has a 2 bytes hole between .sinfo_flags and .sinfo_ppid that
      remains unfilled by us in sctp_ulpevent_read_sndrcvinfo() when
      putting this into cmsg. But also struct sctp_remote_error
      contains a 2 bytes hole that we don't fill but place into a skb
      through skb_copy_expand() via sctp_ulpevent_make_remote_error().
      
      Both structures are defined by the IETF in RFC6458:
      
      * Section 5.3.2. SCTP Header Information Structure:
      
        The sctp_sndrcvinfo structure is defined below:
      
        struct sctp_sndrcvinfo {
          uint16_t sinfo_stream;
          uint16_t sinfo_ssn;
          uint16_t sinfo_flags;
          <-- 2 bytes hole  -->
          uint32_t sinfo_ppid;
          uint32_t sinfo_context;
          uint32_t sinfo_timetolive;
          uint32_t sinfo_tsn;
          uint32_t sinfo_cumtsn;
          sctp_assoc_t sinfo_assoc_id;
        };
      
      * 6.1.3. SCTP_REMOTE_ERROR:
      
        A remote peer may send an Operation Error message to its peer.
        This message indicates a variety of error conditions on an
        association. The entire ERROR chunk as it appears on the wire
        is included in an SCTP_REMOTE_ERROR event. Please refer to the
        SCTP specification [RFC4960] and any extensions for a list of
        possible error formats. An SCTP error notification has the
        following format:
      
        struct sctp_remote_error {
          uint16_t sre_type;
          uint16_t sre_flags;
          uint32_t sre_length;
          uint16_t sre_error;
          <-- 2 bytes hole  -->
          sctp_assoc_t sre_assoc_id;
          uint8_t  sre_data[];
        };
      
      Fix this by setting both to 0 before filling them out. We also
      have other structures shared between user and kernel space in
      SCTP that contains holes (e.g. struct sctp_paddrthlds), but we
      copy that buffer over from user space first and thus don't need
      to care about it in that cases.
      
      While at it, we can also remove lengthy comments copied from
      the draft, instead, we update the comment with the correct RFC
      number where one can look it up.
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8f2e5ae4
    • Benjamin LaHaise's avatar
      aio: protect reqs_available updates from changes in interrupt handlers · 263782c1
      Benjamin LaHaise authored
      As of commit f8567a38 it is now possible to
      have put_reqs_available() called from irq context.  While put_reqs_available()
      is per cpu, it did not protect itself from interrupts on the same CPU.  This
      lead to aio_complete() corrupting the available io requests count when run
      under a heavy O_DIRECT workloads as reported by Robert Elliott.  Fix this by
      disabling irq updates around the per cpu batch updates of reqs_available.
      
      Many thanks to Robert and folks for testing and tracking this down.
      Reported-by: default avatarRobert Elliot <Elliott@hp.com>
      Tested-by: default avatarRobert Elliot <Elliott@hp.com>
      Signed-off-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@infradead.org>
      Cc: stable@vger.kenel.org
      263782c1
    • Fabian Frederick's avatar
      fuse: replace count*size kzalloc by kcalloc · f2b3455e
      Fabian Frederick authored
      kcalloc manages count*sizeof overflow.
      Signed-off-by: default avatarFabian Frederick <fabf@skynet.be>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      f2b3455e
    • Maxim Patlasov's avatar
      fuse: release temporary page if fuse_writepage_locked() failed · 27f1b363
      Maxim Patlasov authored
      tmp_page to be freed if fuse_write_file_get() returns NULL.
      Signed-off-by: default avatarMaxim Patlasov <mpatlasov@parallels.com>
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@suse.cz>
      27f1b363
    • Takashi Iwai's avatar
      ALSA: hda - Revert stream assignment order for Intel controllers · cd50065b
      Takashi Iwai authored
      We got a regression report for 3.15.x kernels, and this turned out to
      be triggered by the fix for stream assignment order.  On reporter's
      machine with Intel controller (8086:1e20) + VIA VT1802 codec, the
      first playback slot can't work with speaker outputs.
      
      But the original commit was actually a fix for AMD controllers where
      no proper GCAP value is returned, we shouldn't revert the whole
      commit.  Instead, in this patch, a new flag is introduced to determine
      the stream assignment order, and follow the old behavior for Intel
      controllers.
      
      Fixes: dcb32ecd ('ALSA: hda - Do not assign streams in reverse order')
      Reported-and-tested-by: default avatarSteven Newbury <steve@snewbury.org.uk>
      Cc: <stable@vger.kernel.org> [v3.15+]
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      cd50065b
    • françois romieu's avatar
      845d6fcc
    • Florian Fainelli's avatar
      net: bcmgenet: fix RGMII_MODE_EN bit · 5a680fad
      Florian Fainelli authored
      RGMII_MODE_EN bit was defined to 0, while it is actually 6. It was not
      much of a problem on older designs where this was a no-op, and the RGMII
      data-path would always be enabled, but newer GENET controllers need to
      explicitely enable their RGMII data-pad using this bit.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5a680fad
    • Andrea Adami's avatar
      mtd: cfi_cmdset_0001.c: add support for Sharp LH28F640BF NOR · 812c5fa8
      Andrea Adami authored
      This family of chips was long ago supported by the pre-cfi driver.
      CFI code tested on several Zaurus SL-5500 (Collie) 2x16 on 32 bit bus.
      
      Function is_LH28F640BF() mimics is_m29ew() from cmdset_0002.c
      
      Buffer write fixes as seen in 2007 patch c/o
      Anti Sullin <anti.sullin <at> artecdesign.ee>
      http://comments.gmane.org/gmane.linux.ports.arm.kernel/36733
      
      [Brian: this patch is semi-urgent, because the following patch switches
        to using CFI detection for a chip which (until now) is unsupported by
        the CFI driver
      
        92183103  ARM: 8084/1: sa1100: collie: revert back to cfi_probe
      ]
      Signed-off-by: default avatarAndrea Adami <andrea.adami@gmail.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      812c5fa8
    • Thomas Petazzoni's avatar
      mtd: nand: reduce the warning noise when the ECC is too weak · 54c39e9b
      Thomas Petazzoni authored
      In commit 67a9ad9b ("mtd: nand: Warn the user if the selected ECC
      strength is too weak"), a check was added to inform the user when the
      ECC used for a NAND device is weaker than the recommended ECC
      advertised by the NAND chip. However, the warning uses WARN_ON(),
      which has two undesirable side-effects:
      
       - It just prints to the kernel log the fact that there is a warning
         in this file, at this line, but it doesn't explain anything about
         the warning itself.
      
       - It dumps a stack trace which is very noisy, for something that the
         user is most likely not able to fix. If a certain ECC used by the
         kernel is weaker than the advertised one, it's most likely to make
         sure the kernel uses an ECC that is compatible with the one used by
         the bootloader, and changing the bootloader may not necessarily be
         easy. Therefore, normal users would not be able to do anything to
         fix this very noisy warning, and will have to suffer from it at
         every kernel boot. At least every time I see this stack trace in my
         kernel boot log, I wonder what new thing is broken, just to realize
         that it's once again this NAND ECC warning.
      
      Therefore, this commit turns:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
      [<c000e3dc>] (unwind_backtrace) from [<c000bee4>] (show_stack+0x10/0x14)
      [<c000bee4>] (show_stack) from [<c0018180>] (warn_slowpath_common+0x6c/0x8c)
      [<c0018180>] (warn_slowpath_common) from [<c001823c>] (warn_slowpath_null+0x1c/0x24)
      [<c001823c>] (warn_slowpath_null) from [<c02c50cc>] (nand_scan_tail+0x538/0x780)
      [<c02c50cc>] (nand_scan_tail) from [<c0639f78>] (orion_nand_probe+0x224/0x2e4)
      [<c0639f78>] (orion_nand_probe) from [<c026da00>] (platform_drv_probe+0x18/0x4c)
      [<c026da00>] (platform_drv_probe) from [<c026c1f4>] (really_probe+0x80/0x218)
      [<c026c1f4>] (really_probe) from [<c026c47c>] (__driver_attach+0x98/0x9c)
      [<c026c47c>] (__driver_attach) from [<c026a8f0>] (bus_for_each_dev+0x64/0x94)
      [<c026a8f0>] (bus_for_each_dev) from [<c026bae4>] (bus_add_driver+0x144/0x1ec)
      [<c026bae4>] (bus_add_driver) from [<c026cb00>] (driver_register+0x78/0xf8)
      [<c026cb00>] (driver_register) from [<c026da5c>] (platform_driver_probe+0x20/0xb8)
      [<c026da5c>] (platform_driver_probe) from [<c00088b8>] (do_one_initcall+0x80/0x1d8)
      [<c00088b8>] (do_one_initcall) from [<c0620c9c>] (kernel_init_freeable+0xf4/0x1b4)
      [<c0620c9c>] (kernel_init_freeable) from [<c049a098>] (kernel_init+0x8/0xec)
      [<c049a098>] (kernel_init) from [<c00095f0>] (ret_from_fork+0x14/0x24)
      ---[ end trace 62f87d875aceccb4 ]---
      
      Into the much shorter, and much more useful:
      
      nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarBrian Norris <computersforpeace@gmail.com>
      54c39e9b
  4. 13 Jul, 2014 10 commits
    • Linus Torvalds's avatar
      Linux 3.16-rc5 · 1795cd9b
      Linus Torvalds authored
      1795cd9b
    • Linus Torvalds's avatar
      Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 · 18b34d9a
      Linus Torvalds authored
      Pull ext4 bugfixes from Ted Ts'o:
       "More bug fixes for ext4 -- most importantly, a fix for a bug
        introduced in 3.15 that can end up triggering a file system corruption
        error after a journal replay.
      
        It shouldn't lead to any actual data corruption, but it is scary and
        can force file systems to be remounted read-only, etc"
      
      * tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
        ext4: fix potential null pointer dereference in ext4_free_inode
        ext4: fix a potential deadlock in __ext4_es_shrink()
        ext4: revert commit which was causing fs corruption after journal replays
        ext4: disable synchronous transaction batching if max_batch_time==0
        ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
        ext4: clarify error count warning messages
        ext4: fix unjournalled bg descriptor while initializing inode bitmap
      18b34d9a
    • Linus Torvalds's avatar
      Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux · 502fde1a
      Linus Torvalds authored
      Pull clock driver fixes from Mike Turquette:
       "This batch of fixes is for a handful of clock drivers from Allwinner,
        Samsung, ST & TI.  Most of them are of the "this hardware won't work
        without this fix" variety, including patches that fix platforms that
        did not boot under certain configurations.  Other fixes are the result
        of changes to the clock core introduced in 3.15 that had subtle
        impacts on the clock drivers.
      
        There are no fixes to the clock framework core in this pull request"
      
      * tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
        clk: spear3xx: Set proper clock parent of uart1/2
        clk: spear3xx: Use proper control register offset
        clk: qcom: HDMI source sel is 3 not 2
        clk: sunxi: fix devm_ioremap_resource error detection code
        clk: s2mps11: Fix double free corruption during driver unbind
        clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
        clk: exynos5420: Remove aclk66_peric from the clock tree description
        clk/exynos5250: fix bit number for tv sysmmu clock
        clk: s3c64xx: Hookup SPI clocks correctly
        clk: samsung: exynos4: Remove SRC_MASK_ISP gates
        clk: samsung: add more aliases for s3c24xx
        clk: samsung: fix several typos to fix boot on s3c2410
        clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
        clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
        clk: ti: dra7: return error code in failure case
        clk: ti: apll: not allocating enough data
      502fde1a
    • Linus Torvalds's avatar
      Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc · 2f3870e9
      Linus Torvalds authored
      Pull ARM SoC fixes from Olof Johansson:
       "This week's arm-soc fixes:
      
         - Another set of OMAP fixes
           * Clock fixes
           * Restart handling
           * PHY regulators
           * SATA hwmod data for DRA7
           + Some trivial fixes and removal of a bit of dead code
         - Exynos fixes
           * A bunch of clock fixes
           * Some SMP fixes
           * Exynos multi-core timer: register as clocksource and fix ftrace.
           + a few other minor fixes
      
        There's also a couple more patches, and at91 fix for USB caused by
        common clock conversion, and more MAINTAINERS entries for shmobile.
      
        We're definitely switching to only regression fixes from here on out,
        we've been a little less strict than usual up until now"
      
      * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
        ARM: at91: at91sam9x5: add clocks for usb device
        ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
        ARM: dts: Add clock property for mfc_pd in exynos5420
        clk: exynos5420: Add IDs for clocks used in PD mfc
        ARM: EXYNOS: Add support for clock handling in power domain
        ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
        ARM: imx: fix shared gate clock
        ARM: dts: Update the parent for Audss clocks in Exynos5420
        ARM: EXYNOS: Update secondary boot addr for secure mode
        ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
        ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio
        ARM: dts: am335x-evm: Enable the McASP FIFO for audio
        ARM: OMAP2+: Make GPMC skip disabled devices
        ARM: OMAP2+: create dsp device only on OMAP3 SoCs
        ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
        ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
        ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
        ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
        ARM: DRA7: hwmod: Fixup SATA hwmod
        ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
        ...
      2f3870e9
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · 5fa77b54
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Another round of fixes for ARM:
         - a set of kprobes fixes from Jon Medhurst
         - fix the revision checking for the L2 cache which wasn't noticed to
           have been broken"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: l2c: fix revision checking
        ARM: kprobes: Fix test code compilation errors for ARMv4 targets
        ARM: kprobes: Disallow instructions with PC and register specified shift
        ARM: kprobes: Prevent known test failures stopping other tests running
      5fa77b54
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k · 33fe3aee
      Linus Torvalds authored
      Pull m68k fixes from Geert Uytterhoeven:
       "Summary:
        - Fix for a boot regression introduced in v3.16-rc1,
        - Fix for a build issue in -next"
      
      Christoph Hellwig questioned why mach_random_get_entropy should be
      exported to modules, and Geert explains that random_get_entropy() is
      called by at least the crypto layer and ends up using it on m68k.  On
      most other architectures it just uses get_cycles() (which is typically
      inlined and doesn't need exporting),
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
        m68k: Export mach_random_get_entropy to modules
        m68k: Fix boot regression on machines with RAM at non-zero
      33fe3aee
    • Linus Torvalds's avatar
      Merge branch 'parisc-3.16-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 54f8c2aa
      Linus Torvalds authored
      Pull parisc fixes from Helge Deller:
       "The major patch in here is one which fixes the fanotify_mark() syscall
        in the compat layer of the 64bit parisc kernel.  It went unnoticed so
        long, because the calling syntax when using a 64bit parameter in a
        32bit syscall is quite complex and even worse, it may be even
        different if you call syscall() or the glibc wrapper.  This patch
        makes the kernel accept the calling convention when called by the
        glibc wrapper.
      
        The other two patches are trivial and remove unused headers, #includes
        and adds the serial ports of the fastest C8000 workstation to the
        parisc-kernel internal hardware database"
      
      * 'parisc-3.16-5' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: drop unused defines and header includes
        parisc: fix fanotify_mark() syscall on 32bit compat kernel
        parisc: add serial ports of C8000/1GHz machine to hardware database
      54f8c2aa
    • Geert Uytterhoeven's avatar
      firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA · 655fc39b
      Geert Uytterhoeven authored
      Commit b3d681a4 ("firewire: Use
      COMPILE_TEST for build testing") added COMPILE_TEST as an alternative
      dependency for the purpose of build testing the firewire core.
      However, this bypasses all other implicit dependencies assumed by PCI,
      like HAS_DMA.
      
      If NO_DMA=y:
      
          drivers/built-in.o: In function `fw_iso_buffer_destroy':
          (.text+0x36a096): undefined reference to `dma_unmap_page'
          drivers/built-in.o: In function `fw_iso_buffer_map_dma':
          (.text+0x36a164): undefined reference to `dma_map_page'
          drivers/built-in.o: In function `fw_iso_buffer_map_dma':
          (.text+0x36a172): undefined reference to `dma_mapping_error'
          drivers/built-in.o: In function `sbp2_send_management_orb':
          sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single'
          sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `sbp2_map_scatterlist':
          sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map'
          sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error'
          sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap'
          drivers/built-in.o: In function `sbp2_unmap_scatterlist':
          sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap'
          sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `complete_command_orb':
          sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single'
          drivers/built-in.o: In function `sbp2_scsi_queuecommand':
          sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single'
          sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error'
      
      Add an explicit dependency on HAS_DMA to fix this.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarJean Delvare <jdelvare@suse.de>
      Signed-off-by: default avatarStefan Richter <stefanr@s5r6.in-berlin.de>
      655fc39b
    • Thomas Gleixner's avatar
      clk: spear3xx: Set proper clock parent of uart1/2 · 44943777
      Thomas Gleixner authored
      The uarts only work when the parent is ras_ahb_clk. The stale 3.5
      based ST tree does this in the board file.
      
      Add it to the clk init function. Not pretty, but the mess there is
      amazing anyway.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      44943777
    • Thomas Gleixner's avatar
      clk: spear3xx: Use proper control register offset · 15ebb052
      Thomas Gleixner authored
      The control register is at offset 0x10, not 0x0. This is wreckaged
      since commit 5df33a62 (SPEAr: Switch to common clock framework).
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarMike Turquette <mturquette@linaro.org>
      15ebb052