1. 23 2月, 2017 34 次提交
  2. 22 2月, 2017 6 次提交
    • J
      HID: rmi: fallback to generic/multitouch if hid-rmi is not built · 2fa299a9
      Jiri Kosina 提交于
      Commit 279967a6 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
      unconditionally switches over handling of all Synaptics touchpads to hid-rmi
      (to make use of extended features of the HW); in case CONFIG_HID_RMI is
      disabled though this renders the touchpad unusable, as the
      
      	HID_DEVICE(HID_BUS_ANY, HID_GROUP_RMI, HID_ANY_ID, HID_ANY_ID)
      
      match doesn't exist and generic/multitouch doesn't bind to it either (due
      to hid group mismatch).
      
      Fix this by switching over to hid-rmi only if it has been actually built.
      
      Fixes: 279967a6 ("HID: rmi: Handle all Synaptics touchpads using hid-rmi")
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Acked-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Tested-by: NAndrew Duggan <aduggan@synaptics.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      2fa299a9
    • K
      Revert "ath10k: Search SMBIOS for OEM board file extension" · 005c3490
      Kalle Valo 提交于
      This reverts commit f2593cb1.
      
      Paul reported that this patch with older board-2.bin ath10k initialisation
      fails on Dell XPS 13:
      
      ath10k_pci 0000:3a:00.0: failed to fetch board data for bus=pci,vendor=168c,
      device=003e,subsystem-vendor=1a56,subsystem-device=1535,variant=RV_0520 from
      ath10k/QCA6174/hw3.0/board-2.bin
      
      The reason is that the older board-2.bin does not have the variant version of
      the image name and ath10k does not fallback to the older naming scheme.
      Reported-by: NPaul Menzel <pmenzel@molgen.mpg.de>
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=185621#c9
      Fixes: f2593cb1 ("ath10k: Search SMBIOS for OEM board file extension")
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      005c3490
    • T
      bnxt_en: use eth_hw_addr_random() · 1faaa78f
      Tobias Klauser 提交于
      Use eth_hw_addr_random() to set a random MAC address in order to make
      sure bp->dev->addr_assign_type will be properly set to NET_ADDR_RANDOM.
      Signed-off-by: NTobias Klauser <tklauser@distanz.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1faaa78f
    • T
      net: mvpp2: enable building on 64-bit platforms · d3158807
      Thomas Petazzoni 提交于
      The mvpp2 is going to be extended to support the Marvell Armada 7K/8K
      platform, which is ARM64. As a preparation to this work, this commit
      enables building the mvpp2 driver on ARM64, by:
      
       - Adjusting the Kconfig dependency
      
       - Fixing the types used in the driver so that they are 32/64-bits
         compliant. We use dma_addr_t for DMA addresses, and unsigned long
         for virtual addresses.
      
      It is worth mentioning that after this commit, the driver is for now
      still only used on 32-bits platforms, and will only work on 32-bits
      platforms.
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d3158807
    • T
      net: mvpp2: switch to build_skb() in the RX path · 0e037281
      Thomas Petazzoni 提交于
      This commit adapts the mvpp2 RX path to use the build_skb() method. Not
      only build_skb() is now the recommended mechanism, but it also
      simplifies the addition of support for the PPv2.2 variant.
      
      Indeed, without build_skb(), we have to keep track for each RX
      descriptor of the physical address of the packet buffer, and the virtual
      address of the SKB. However, in PPv2.2 running on 64 bits platform,
      there is not enough space in the descriptor to store the virtual address
      of the SKB. So having to take care only of the address of the packet
      buffer, and building the SKB upon reception helps in supporting PPv2.2.
      
      The implementation is fairly straightforward:
      
       - mvpp2_skb_alloc() is renamed to mvpp2_buf_alloc() and no longer
         allocates a SKB. Instead, it allocates a buffer using the new
         mvpp2_frag_alloc() function, with enough space for the data and SKB.
      
       - The initialization of the RX buffers in mvpp2_bm_bufs_add() as well
         as the refill of the RX buffers in mvpp2_rx_refill() is adjusted
         accordingly.
      
       - Finally, the mvpp2_rx() is modified to use build_skb().
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e037281
    • T
      net: mvpp2: simplify MVPP2_PRS_RI_* definitions · 8138affc
      Thomas Petazzoni 提交于
      Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
      doesn't compile nicely on 64-bit. Moreover, those definitions are in
      fact unneeded, since they are always used in combination with a bit
      mask that ensures only the appropriate bits are modified.
      
      Therefore, such definitions should just be set to 0x0. In addition, as
      suggested by Russell King, we change the _MASK definitions to also use
      the BIT() macro so that it is clear they are related to the values
      defined afterwards.
      
      For example:
      
       #define MVPP2_PRS_RI_L2_CAST_MASK              0x600
       #define MVPP2_PRS_RI_L2_UCAST                  ~(BIT(9) | BIT(10))
       #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
       #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)
      
      becomes
      
       #define MVPP2_PRS_RI_L2_CAST_MASK              (BIT(9) | BIT(10))
       #define MVPP2_PRS_RI_L2_UCAST                  0x0
       #define MVPP2_PRS_RI_L2_MCAST                  BIT(9)
       #define MVPP2_PRS_RI_L2_BCAST                  BIT(10)
      
      Because the values (MVPP2_PRS_RI_L2_UCAST, MVPP2_PRS_RI_L2_MCAST and
      MVPP2_PRS_RI_L2_BCAST) are always applied with
      MVPP2_PRS_RI_L2_CAST_MASK, and therefore there is no need for
      MVPP2_PRS_RI_L2_UCAST to be defined as ~(BIT(9) | BIT(10)).
      
      It fixes the following warnings when building the driver on a 64-bit
      platform (which is not possible as of this commit, but will be enabled
      in a follow-up commit):
      
      drivers/net/ethernet/marvell/mvpp2.c: In function ‘mvpp2_prs_mac_promisc_set’:
      drivers/net/ethernet/marvell/mvpp2.c:524:33: warning: large integer implicitly truncated to unsigned type [-Woverflow]
       #define MVPP2_PRS_RI_L2_UCAST   ~(BIT(9) | BIT(10))
                                       ^
      drivers/net/ethernet/marvell/mvpp2.c:1459:33: note: in expansion of macro ‘MVPP2_PRS_RI_L2_UCAST’
         mvpp2_prs_sram_ri_update(&pe, MVPP2_PRS_RI_L2_UCAST,
      Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8138affc