1. 08 5月, 2013 8 次提交
  2. 07 5月, 2013 3 次提交
  3. 06 5月, 2013 1 次提交
  4. 05 5月, 2013 11 次提交
  5. 04 5月, 2013 9 次提交
    • J
      hwmon: (lm75) Add support for the Dallas/Maxim DS7505 · 3fbc81e3
      Jean Delvare 提交于
      Basically it's the same as the original DS75 but much faster.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      3fbc81e3
    • J
      hwmon: (lm75) Tune resolution and sample time per chip · 0cd2c72d
      Jean Delvare 提交于
      Most LM75-compatible chips can either sample much faster or with a
      much better resolution than the original LM75 chip. So far the lm75
      driver did not let the user take benefit of these improvements. Do it
      now.
      
      I decided to almost always configure the chip to use the best
      resolution possible, which also means the longest sample time. The
      only chips for which I didn't are the DS75, DS1775 and STDS75, because
      they are really too slow in 12-bit mode (1.2 to 1.5 second worst case)
      so I went for 11-bit mode as a more reasonable tradeoff. This choice is
      dictated by the fact that the hwmon subsystem is meant for system
      monitoring, it has never been supposed to be ultra-fast, and as a
      matter of fact we do cache the sampled values in almost all drivers.
      
      If anyone isn't pleased with these default settings, they can always
      introduce a platform data structure or DT support for the lm75. That
      being said, it seems nobody ever complained that the driver wouldn't
      refresh the value faster than every 1.5 second, and the change made
      it faster for all chips even in 12-bit mode, so I don't expect any
      complaint.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      0cd2c72d
    • J
      hwmon: (lm75) Prepare to support per-chip resolution and sample time · 87d0621a
      Jean Delvare 提交于
      Prepare the lm75 driver to support per-chip resolution and sample
      time. For now we only make the code generic enough to support it, but
      we still use the same, unchanged resolution (9-bit) and sample time
      (1.5 s) for all chips.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      87d0621a
    • J
      hwmon: (lm75) Per-chip configuration register initialization · 8a5c5cc6
      Jean Delvare 提交于
      There is no standard for the configuration register bits of LM75-like
      chips. We shouldn't blindly clear bits setting the resolution as they
      are either unused or used for something else on some of the supported
      chips.
      
      So, switch to per-chip configuration initialization. This will allow
      for better tuning later, for example using more resolution bits when
      available.
      Signed-off-by: NJean Delvare <khali@linux-fr.org>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      8a5c5cc6
    • T
      cxgb4: fix error recovery when t4_fw_hello returns a positive value · 777c2300
      Thadeu Lima de Souza Cascardo 提交于
      Since commit 636f9d37 ("cxgb4: Add
      support for T4 configuration file"), t4_fw_hello may return a positive
      value instead of 0 for success. The recovery code tests only for zero
      and fails recovery for any other value.
      
      This fix tests for negative error values and fails only on those cases.
      Error recovery after an error injection works after this change.
      Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      777c2300
    • K
      sky2: Fix crash on receiving VLAN frames · 88dccf5b
      Kirill Smelkov 提交于
      After recent 86a9bad3 (net: vlan: add protocol argument to packet
      tagging functions) my sky2 started to crash on receive of tagged
      frames, with backtrace similar to
      
          #CRASH!!!
          vlan_do_receive
          __netif_receive_skb_core
          __netif_receive_skb
          netif_receive_skb
          sky2_poll
          ...
          __net_rx_action
          __do_softirq
      
      The problem turned out to be:
      
          1) sky2 copies small packets from ring on RX, and in its
             receive_copy() skb header is copied manually field, by field, and
             only for some fields;
      
          2) 86a9bad3  added skb->vlan_proto, which vlan_untag() or
             __vlan_hwaccel_put_tag() set, and which is later used in
             vlan_do_receive().
      
             That patch updated copy_skb_header() for newly introduced
             skb->vlan_proto, but overlooked the need to also copy it in sky2's
             receive_copy().
      
      Because of 2, we have the following scenario:
      
          - frame is received and tagged in a ring, by sky2_rx_tag(). Both
            skb->vlan_proto and skb->vlan_tci are set;
      
          - later skb is decided to be copied, but skb->vlan_proto is
            forgotten and becomes 0.
      
          - in the beginning of vlan_do_receive() we call
      
              __be16 vlan_proto = skb->vlan_proto;
              vlan_dev = vlan_find_dev(skb->dev, vlan_proto, vlan_id);
      
            which eventually invokes
      
              vlan_proto_idx(vlan_proto)
      
            and that routine BUGs for everything except ETH_P_8021Q and
            ETH_P_8021AD.
      
            Oops.
      
      Fix it.
      
      P.S.
      
      Stephen, I wonder, why copy_skb_header() is not used in
      sky2.c::receive_copy() ? Problems, where receive_copy was updated field
      by field showed several times already, e.g.
      
          3f42941b    (sky2: propogate rx hash when packet is copied)
          e072b3fa    (sky2: fix receive length error in mixed non-VLAN/VLAN traffic)
      
      Cc: Patrick McHardy <kaber@trash.net>
      Cc: Stephen Hemminger <stephen@networkplumber.org>
      Cc: Mirko Lindner <mlindner@marvell.com>
      Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
      Acked-by: NStephen Hemminger <stephen@networkplumber.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      88dccf5b
    • H
      asix: fix BUG in receive path when lowering MTU · c5060cec
      holger@eitzenberger.org 提交于
      There is bug in the receive path of the asix driver at the time a
      packet is received larger than MTU size and DF bit set:
      
       BUG: unable to handle kernel paging request at 0000004000000001
       IP: [<ffffffff8126f65b>] skb_release_head_state+0x2d/0xd2
       ...
       Call Trace:
        <IRQ>
        [<ffffffff8126f86d>] ? skb_release_all+0x9/0x1e
        [<ffffffff8126f8ad>] ? __kfree_skb+0x9/0x6f
        [<ffffffffa00b4200>] ? asix_rx_fixup_internal+0xff/0x1ae [asix]
        [<ffffffffa00fb3dc>] ? usbnet_bh+0x4f/0x226 [usbnet]
        ...
      
      It is easily reproducable by setting an MTU of 512 e. g. and sending
      something like
      
        ping -s 1472 -c 1 -M do $SELF
      
      from another box.
      
      And this is because the rx->ax_skb is freed on error, but rx->ax_skb
      is not reset, and the size is not reset to zero in this case.
      
      And since the skb is added again to the usbnet->done skb queue it is
      accessing already freed memory, resulting in the BUG when freeing a
      2nd time.  I therefore think the value 0x0000004000000001 show in the
      trace is more or less random data.
      Signed-off-by: NHolger Eitzenberger <holger@eitzenberger.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5060cec
    • T
      net: qmi_wwan: Add Telewell TW-LTE 4G · 0decc64b
      Teppo Kotilainen 提交于
      Information from driver description files:
      
        diag:  VID_19D2&PID_0412&MI_00
        nmea:  VID_19D2&PID_0412&MI_01
        at:    VID_19D2&PID_0412&MI_02
        modem: VID_19D2&PID_0412&MI_03
        net:   VID_19D2&PID_0412&MI_04
      Signed-off-by: NTeppo Kotilainen <qubit303@gmail.com>
      Acked-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0decc64b
    • D
      usbnet: pegasus: endian bug in write_mii_word() · 3d64fc70
      Dan Carpenter 提交于
      We're only passing the two high bytes of an integer.  It works for
      little endian but not for big endian.
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d64fc70
  6. 03 5月, 2013 8 次提交