1. 26 8月, 2015 1 次提交
    • G
      PCI: Make pci_msi_setup_pci_dev() non-static for use by arch code · 22b6839b
      Guilherme G. Piccoli 提交于
      Commit 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel
      doesn't support MSI") changed the location of the code that initialises
      dev->msi_cap/msix_cap and then disables MSI/MSI-X interrupts at PCI
      probe time in devices that have this flag set. It moved the code from
      pci_msi_init_pci_dev() to a new function named pci_msi_setup_pci_dev(),
      called by pci_setup_device().
      
      The pseries PCI probing code does not call pci_setup_device(), so since
      the aforementioned commit the function pci_msi_setup_pci_dev() is not
      called and MSI/MSI-X interrupts are left enabled. Additionally because
      dev->msi_cap/msix_cap are not initialised no driver can ever enable
      MSI/MSI-X.
      
      To fix this, the pseries PCI probe should manually call
      pci_msi_setup_pci_dev(), so this patch makes it non-static.
      
      Fixes: 1851617c ("PCI/MSI: Disable MSI at enumeration even if kernel doesn't support MSI")
      [mpe: Update change log to mention dev->msi_cap/msix_cap]
      Signed-off-by: NGuilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      22b6839b
  2. 22 8月, 2015 1 次提交
    • M
      mm: make page pfmemalloc check more robust · 2f064f34
      Michal Hocko 提交于
      Commit c48a11c7 ("netvm: propagate page->pfmemalloc to skb") added
      checks for page->pfmemalloc to __skb_fill_page_desc():
      
              if (page->pfmemalloc && !page->mapping)
                      skb->pfmemalloc = true;
      
      It assumes page->mapping == NULL implies that page->pfmemalloc can be
      trusted.  However, __delete_from_page_cache() can set set page->mapping
      to NULL and leave page->index value alone.  Due to being in union, a
      non-zero page->index will be interpreted as true page->pfmemalloc.
      
      So the assumption is invalid if the networking code can see such a page.
      And it seems it can.  We have encountered this with a NFS over loopback
      setup when such a page is attached to a new skbuf.  There is no copying
      going on in this case so the page confuses __skb_fill_page_desc which
      interprets the index as pfmemalloc flag and the network stack drops
      packets that have been allocated using the reserves unless they are to
      be queued on sockets handling the swapping which is the case here and
      that leads to hangs when the nfs client waits for a response from the
      server which has been dropped and thus never arrive.
      
      The struct page is already heavily packed so rather than finding another
      hole to put it in, let's do a trick instead.  We can reuse the index
      again but define it to an impossible value (-1UL).  This is the page
      index so it should never see the value that large.  Replace all direct
      users of page->pfmemalloc by page_is_pfmemalloc which will hide this
      nastiness from unspoiled eyes.
      
      The information will get lost if somebody wants to use page->index
      obviously but that was the case before and the original code expected
      that the information should be persisted somewhere else if that is
      really needed (e.g.  what SLAB and SLUB do).
      
      [akpm@linux-foundation.org: fix blooper in slub]
      Fixes: c48a11c7 ("netvm: propagate page->pfmemalloc to skb")
      Signed-off-by: NMichal Hocko <mhocko@suse.com>
      Debugged-by: NVlastimil Babka <vbabka@suse.com>
      Debugged-by: NJiri Bohac <jbohac@suse.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NMel Gorman <mgorman@suse.de>
      Cc: <stable@vger.kernel.org>	[3.6+]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2f064f34
  3. 20 8月, 2015 1 次提交
  4. 19 8月, 2015 3 次提交
  5. 18 8月, 2015 1 次提交
    • V
      regulator: core: Define regulator_set_voltage_triplet() · 30f93ca8
      Viresh Kumar 提交于
      Voltage tolerance isn't necessarily same on both sides of the target
      voltage and regulator_set_voltage_tol() wouldn't be suitable in such
      cases.
      
      Add another routine regulator_set_voltage_triplet(), which accepts
      target, min and max voltages as arguments.
      
      This first tries to set the voltage between the target voltage and the
      upper limit, then fall back on the full range. The idea behind this is
      to set regulator's voltage as close to the target voltage, as possible.
      
      Based on regulator_set_voltage_tol().
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      30f93ca8
  6. 15 8月, 2015 5 次提交
  7. 14 8月, 2015 5 次提交
    • P
      usb: chipidea: add tx/rx burst size configuration interface · 96625ead
      Peter Chen 提交于
      The user can adjust it through dts or platform data
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      96625ead
    • P
      usb: chipidea: add ahb burst configuration interface · 65668718
      Peter Chen 提交于
      The users can change it through dts or platform data if they
      want to change the default value.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      65668718
    • P
      usb: chipidea: define stream mode disable for both roles · 8022d3d5
      Peter Chen 提交于
      The system bus and chipidea IP have different limitations for
      both host and device mode.
      For example, with below errata, we need to enable SDIS(Stream Disable
      Mode) at host mode. But we don't want it for device mode at the
      same system.
      
      TAR 9000378958
      Title: Non-Double Word Aligned Buffer Address Sometimes Causes Host to
      Hang on OUT Retry
      Impacted Configuration: Host mode, all transfer types
      Description:
      The host core operating in streaming mode may under run while sending
      the data packet of an OUT transaction. This under run can occur if
      there are unexpected system delays in fetching the remaining packet
      data from memory. The host forces a bad CRC on the packet, the device
      detects the error and discards the packet. The host then retries a Bulk,
      Interrupt, or Control transfer if an under run occurs according to the
      USB specification. During simulations, it was found that the host does
      not issue the retry of the failed bulk OUT. It does not issue any other
      transactions except SOF packets that have incorrect frame numbers.
      
      The second failure mode occurs if the under run occurs on an ISO OUT
      transaction and the next ISO transaction is a zero byte packet. The host
      does not issue any transactions (including SOFs). The device detects a
      Suspend condition, reverts to full speed, and waits for resume signaling.
      
      A third failure mode occurs when the host under runs on an ISO OUT and
      the next ISO in the schedule is an ISO OUT with two max packets of 1024
      bytes each. The host should issue MDATA for the first OUT followed by
      DATA1 for the second. However, it drops the MDATA transaction, and
      issues the DATA1 transaction.
      
      The system impact of this bug is the same regardless of the failure mode
      observed. The host core hangs, the ehci_ctrl state machine waits for the
      protocol engine to send the completion status for the corrupted
      transaction, which never occurs. No indication is sent to the host
      controller driver, no register bits change and no interrupts occur.
      Eventually the requesting application times out.
      
      Detailed internal behavior:
      The EHCI control state machine (ehci_ctrl) in the DMA block is responsible
      for parsing the schedules and initiating all transactions. The ehci_ctrl
      state machine passes the transaction details to the protocol block by
      writing the transaction information in to the TxFIFO. It then asserts
      the pe_hst_run_pkt signal to inform the host protocol state machine
      (pe_hst_state) that there is a packet in the TxFIFO.
      A tag of 0x0 indicates a start of packet with the data providing the
      following information:
      
      35:32 Tag
      31:30 Reserved
      29:23 Endpoint (lowest 4 bits)
      22:16 Address
      15:10 Reserved
      9:8 Endpoint speed
      7:6 Endpoint type
      5:6 Data Toggle
      3:0 PID
      The pe_hst_state reads the packet information and constructs the packet
      and issues it to the PHY interface.
      The ehci_ctrl state machine writes the start transaction information in
      to the TxFIFO as 0x03002910c for the OUT packet that had the under run
      error. However, it writes 0xC3002910C for the retry of the Out
      transaction, which is incorrect.
      The pe_hst_state enters a bus timeout state after sending the bad CRC
      for the packet that under ran. It then purges any data that was back
      filled in to the TxFIFO for the packet that under ran. The pe_hst_state
      machine stops purging the TxFIFO when it is empty or if it reads a
      location that has a tag of 0x0, indicating a start of packet command.
      
      The pe_hst_state reads 0xC3002910C and discards it as it does not decode
      to a start of packet command. It continues to purge the OUT data that
      has been pre-buffered for the OUT retry . The pe_hst_state detects the
      hst_packet_run signal and attempts to read the PID and address
      information from the TxFIFO. This location has packet data and so does
      not decode to a valid PID and so falls through to the PE_HST_SOF_LOAD
      state where the frame_num_counter is updated. The frame_num_counter
      is updated with the data in the TxFIFO. In this case, the data is
      incorrect as the ehci_ctrl state machine did not initiate the load.
      The hst_pe_state machine detects the SOF request signal and sends an
      SOF with the bad frame number. Meanwhile, the ehci_ctrl state machine
      waits indefinitely in the run_pkt state waiting for the completion
      status from pe_hst_state machine, which will never happen.
      
      The ISO failure case is similar except that there is no retry for ISO.
      The ehci_ctrl state machine moves to the next transfer in the periodic
      schedule. If the under run occurs on the last entry of the periodic
      list then it moves to the Async schedule.
      
      In the case of ISO OUT simulations, the next ISO is a zero byte OUT
      and again the start of packet command gets corrupted. The TxFIFO is
      empty when the hst_pe_state attempts to read the Address and PID
      information as the transaction is a zero byte packet. This results
      in the hst_pe_state machine staying in the GET_PID state, which means
      that it does not issue any transactions (including SOFs). The device
      detects a Suspend condition and reverts to full speed mode and waits
      for a Resume or Reset signal.
      
      The EHCI specification allows a Non-DoubleWord (32 bits) offset to
      be used as a current offset for Buffer Pointer Page 0 of the qTD.
      In Non-DoubleWord aligned cases, the core reads the packet data
      from the AHB memory, performs the alignment operation before writing
      it in to the TxFIFO as a 32 bit data word. An End Of Packet tag (EOP)
      is written to the TxFIFO after all the packet data has been written
      in to the TxFIFO. The alignment function is reset to Idle by the EOP
      tag. The corruption of the start of packet command arises because the
      packet buffer for the OUT transaction that under ran is not aligned
      to a DoubleWord, and hence no EOP tag is written to the TxFIFO. The
      alignment function is still active when the start packet information
      is written in to the TxFIFO for the retry of the bulk packet or for
      the next transaction in the case of an under run on an ISO. This
      results in the corruption of the start tag and the transaction
      information.
      
      Click for waveform showing the command 0x 0000300291 being written in
      to the TX FIFO for the Out that under ran.
      Click for waveform showing the command 0xC3002910C written to the
      TxFIFO instead of 0x 0000300291
      Versions affected: Versions 2.10a and previous versions
      How discovered: Customer simulation
      
      Workaround:
      1- The EHCI specification allows a non-DoubleWord offset to be used
      as a current offset for Buffer Pointer Page 0 of the qTD. However,
      if a DoubleWord offset is used then this issue does not arise.
      2- Use non streaming mode to eliminate under runs.
      
      Resolution:
      The fix involves changes to the traffic state machine in the
      vusb_hs_dma_traf block. The ehci_ctrl state machine updates the context
      information by encoding the transaction results on the
      hst_op_context_update signals at the end of a transaction. The signal
      hst_op_context_update is added to the traffic state machine, and the
      tx_fifo_under_ran_r signal is generated if the transaction results in
      an under run error. Click for waveform
      
      The traffic state machine then traverses to the do_eop states if the
      tx_fifo_under_ran error is asserted. Thus an EOP tag is written in to
      the TxFIFO as shown in this waveform .
      
      The EOP tag resets the align state machine to the Idle state ensuring
      that the next command written by the echi_ctrl state machine does not
      get corrupted.
      
      File(s) modified:
      RTL code fixed: …..
      Method of reproducing: This failure cannot be reproduced in the current
      test bench.
      Date Found: March 2010
      Date Fixed: June 2010
      Update information:
      Added the RTL code fix
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      8022d3d5
    • P
      usb: chipidea: introduce ITC tuning interface · df96ed8d
      Peter Chen 提交于
      ITC (Interrupt Threshold Control) is used to set the maximum rate at which
      the host/device controller will issue interrupts. The default value is 8 (1ms)
      for it. EHCI core will modify it to 1, but device mode keeps it as default
      value.
      
      In some use cases like Android ADB, it only has one usb request for each
      direction, and maximum payload data is only 4KB, so the speed is 4MB/s
      at most, it needs controller to trigger interrupt as fast as possible
      to increase the speed. The USB performance will be better if the interrupt
      can be triggered faster.
      
      Reduce ITC value is benefit for USB performance, but the interrupt number
      is increased at the same time, it may increase cpu utilization too.
      Most of use case cares about performance, but some may care about
      cpu utilization, so, we leave a platform interface for user.
      We set ITC as 1 (1 micro-frame) as default value which is aligned
      with ehci core default value.
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      df96ed8d
    • P
      usb: chipidea: add ttctrl.ttha control interface · 28362673
      Peter Chen 提交于
      The register of ttctrl.ttha describes like below:
      - Internal TT Hub Address Representation
      - RW
      - Default = 0000000b
      This field is used to match against the Hub Address field in QH & siTD
      to determine if the packet is routed to the internal TT for directly
      attached FS/LS devices. If the Hub Address in the QH or siTD does not
      match this address then the packet will be broadcast on the High Speed
      ports destined for a downstream High Speed hub with the address in the QH/siTD.
      
      In silicon RTL, this entry only affects QH and siTD, and the hub.addr at
      both QH and siTD are 0 in ehci core for chipidea (with hcd->has_tt = 1).
      
      So, for QH, if the "usage_tt" flag at RTL is 0, set CI_HDRC_SET_NON_ZERO_TTHA
      will not affect QH (with non-hs device); for siTD, set this flag
      will change remaining space requirement for the last transaction from 1023
      bytes to 188 bytes, it can increase the number of transactions within one
      frame, ehci periodic schedule code will not queue the packet if the frame space
      is full, so it is safe to set this flag for siTD.
      
      With this flag, it can fix the problem Alan Stern reported below:
      http://www.spinics.net/lists/linux-usb/msg123125.html
      And may fix Michael Tessier's problem too.
      http://www.spinics.net/lists/linux-usb/msg118679.html
      
      CC: stern@rowland.harvard.edu
      CC: michael.tessier@axiontech.ca
      Signed-off-by: NPeter Chen <peter.chen@freescale.com>
      28362673
  8. 11 8月, 2015 1 次提交
  9. 10 8月, 2015 3 次提交
  10. 09 8月, 2015 1 次提交
  11. 08 8月, 2015 2 次提交
    • L
      iio: Add inverse unit conversion macros · c689a923
      Lars-Peter Clausen 提交于
      Add inverse unit conversion macro to convert from standard IIO units to
      units that might be used by some devices.
      
      Those are useful in combination with scale factors that are specified as
      IIO_VAL_FRACTIONAL. Typically the denominator for those specifications will
      contain the maximum raw value the sensor will generate and the numerator
      the value it maps to in a specific unit. Sometimes datasheets specify those
      in different units than the standard IIO units (e.g. degree/s instead of
      rad/s) and so we need to do a unit conversion.
      
      From a mathematical point of view it does not make a difference whether we
      apply the unit conversion to the numerator or the inverse unit conversion
      to the denominator since (x / y) / z = x / (y * z). But as the denominator
      is typically a larger value and we are rounding both the numerator and
      denominator to integer values using the later method gives us a better
      precision (E.g. the relative error is smaller if we round 8000.3 to 8000
      rather than rounding 8.3 to 8).
      
      This is where in inverse unit conversion macros will be used.
      
      Marked for stable as used by some upcoming fixes.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      c689a923
    • P
      iio: declare struct to fix warning · ad30bad3
      Pengyu Ma 提交于
      When compile iio related driver the following warning shown:
      
      include/linux/iio/trigger.h:35:34: warning: 'struct iio_trigger'
      declared inside parameter list
        int (*set_trigger_state)(struct iio_trigger *trig, bool state);
      
      include/linux/iio/trigger.h:38:18: warning: 'struct iio_dev'
      declared inside parameter list
                 struct iio_dev *indio_dev);
      
      'struct iio_dev' and 'struct iio_trigger' was used before declaration,
      forward declaration for these structs to fix warning.
      Signed-off-by: NPengyu Ma <pengyu.ma@windriver.com>
      Acked-by: NDaniel Baluta <daniel.baluta@intel.com>
      Signed-off-by: NJonathan Cameron <jic23@kernel.org>
      ad30bad3
  12. 07 8月, 2015 2 次提交
    • N
      mm: check __PG_HWPOISON separately from PAGE_FLAGS_CHECK_AT_* · f4c18e6f
      Naoya Horiguchi 提交于
      The race condition addressed in commit add05cec ("mm: soft-offline:
      don't free target page in successful page migration") was not closed
      completely, because that can happen not only for soft-offline, but also
      for hard-offline.  Consider that a slab page is about to be freed into
      buddy pool, and then an uncorrected memory error hits the page just
      after entering __free_one_page(), then VM_BUG_ON_PAGE(page->flags &
      PAGE_FLAGS_CHECK_AT_PREP) is triggered, despite the fact that it's not
      necessary because the data on the affected page is not consumed.
      
      To solve it, this patch drops __PG_HWPOISON from page flag checks at
      allocation/free time.  I think it's justified because __PG_HWPOISON
      flags is defined to prevent the page from being reused, and setting it
      outside the page's alloc-free cycle is a designed behavior (not a bug.)
      
      For recent months, I was annoyed about BUG_ON when soft-offlined page
      remains on lru cache list for a while, which is avoided by calling
      put_page() instead of putback_lru_page() in page migration's success
      path.  This means that this patch reverts a major change from commit
      add05cec about the new refcounting rule of soft-offlined pages, so
      "reuse window" revives.  This will be closed by a subsequent patch.
      Signed-off-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Dean Nelson <dnelson@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: David Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f4c18e6f
    • M
      fs, file table: reinit files_stat.max_files after deferred memory initialisation · 4248b0da
      Mel Gorman 提交于
      Dave Hansen reported the following;
      
      	My laptop has been behaving strangely with 4.2-rc2.  Once I log
      	in to my X session, I start getting all kinds of strange errors
      	from applications and see this in my dmesg:
      
              	VFS: file-max limit 8192 reached
      
      The problem is that the file-max is calculated before memory is fully
      initialised and miscalculates how much memory the kernel is using.  This
      patch recalculates file-max after deferred memory initialisation.  Note
      that using memory hotplug infrastructure would not have avoided this
      problem as the value is not recalculated after memory hot-add.
      
      4.1:             files_stat.max_files = 6582781
      4.2-rc2:         files_stat.max_files = 8192
      4.2-rc2 patched: files_stat.max_files = 6562467
      
      Small differences with the patch applied and 4.1 but not enough to matter.
      Signed-off-by: NMel Gorman <mgorman@suse.de>
      Reported-by: NDave Hansen <dave.hansen@intel.com>
      Cc: Nicolai Stange <nicstange@gmail.com>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Alex Ng <alexng@microsoft.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4248b0da
  13. 06 8月, 2015 14 次提交