1. 01 Oct, 2020 35 commits
  2. 23 Sep, 2020 5 commits
    • Greg Kroah-Hartman's avatar
    • Adam Borowski's avatar
      x86/defconfig: Enable CONFIG_USB_XHCI_HCD=y · a8ee54d7
      Adam Borowski authored
      commit 72a9c673 upstream.
      
      A spanking new machine I just got has all but one USB ports wired as 3.0.
      Booting defconfig resulted in no keyboard or mouse, which was pretty
      uncool.  Let's enable that -- USB3 is ubiquitous rather than an oddity.
      As 'y' not 'm' -- recovering from initrd problems needs a keyboard.
      
      Also add it to the 32-bit defconfig.
      Signed-off-by: default avatarAdam Borowski <kilobyte@angband.pl>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-usb@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181009062803.4332-1-kilobyte@angband.plSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8ee54d7
    • Alexey Kardashevskiy's avatar
      powerpc/dma: Fix dma_map_ops::get_required_mask · 5e35f49d
      Alexey Kardashevskiy authored
      commit 437ef802 upstream.
      
      There are 2 problems with it:
        1. "<" vs expected "<<"
        2. the shift number is an IOMMU page number mask, not an address
        mask as the IOMMU page shift is missing.
      
      This did not hit us before f1565c24 ("powerpc: use the generic
      dma_ops_bypass mode") because we had additional code to handle bypass
      mask so this chunk (almost?) never executed.However there were
      reports that aacraid does not work with "iommu=nobypass".
      
      After f1565c24, aacraid (and probably others which call
      dma_get_required_mask() before setting the mask) was unable to enable
      64bit DMA and fall back to using IOMMU which was known not to work,
      one of the problems is double free of an IOMMU page.
      
      This fixes DMA for aacraid, both with and without "iommu=nobypass" in
      the kernel command line. Verified with "stress-ng -d 4".
      
      Fixes: 6a5c7be5 ("powerpc: Override dma_get_required_mask by platform hook and ops")
      Cc: stable@vger.kernel.org # v3.2+
      Signed-off-by: default avatarAlexey Kardashevskiy <aik@ozlabs.ru>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Link: https://lore.kernel.org/r/20200908015106.79661-1-aik@ozlabs.ruSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e35f49d
    • Quentin Perret's avatar
      ehci-hcd: Move include to keep CRC stable · faf8af43
      Quentin Perret authored
      commit 29231826 upstream.
      
      The CRC calculation done by genksyms is triggered when the parser hits
      EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the
      types of the function parameters, and uses that as the input for the CRC
      calculation. In the case of forward-declared structs, the type expands
      to 'UNKNOWN'. Following this, it appears that the result of the
      expansion of each type is cached somewhere, and seems to be re-used
      when/if the same type is seen again for another exported symbol in the
      same C file.
      
      Unfortunately, this can cause CRC 'stability' issues when a struct
      definition becomes visible in the middle of a C file. For example, let's
      assume code with the following pattern:
      
          struct foo;
      
          int bar(struct foo *arg)
          {
      	/* Do work ... */
          }
          EXPORT_SYMBOL_GPL(bar);
      
          /* This contains struct foo's definition */
          #include "foo.h"
      
          int baz(struct foo *arg)
          {
      	/* Do more work ... */
          }
          EXPORT_SYMBOL_GPL(baz);
      
      Here, baz's CRC will be computed using the expansion of struct foo that
      was cached after bar's CRC calculation ('UNKOWN' here). But if
      EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol
      trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded
      late, during baz's CRC calculation, which now has visibility over the
      full struct definition, hence resulting in a different CRC for baz.
      
      The proper fix for this certainly is in genksyms, but that will take me
      some time to get right. In the meantime, we have seen one occurrence of
      this in the ehci-hcd code which hits this problem because of the way it
      includes C files halfway through the code together with an unlucky mix
      of symbol trimming.
      
      In order to workaround this, move the include done in ehci-hub.c early
      in ehci-hcd.c, hence making sure the struct definitions are visible to
      the entire file. This improves CRC stability of the ehci-hcd exports
      even when symbol trimming is enabled.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarQuentin Perret <qperret@google.com>
      Link: https://lore.kernel.org/r/20200916171825.3228122-1-qperret@google.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      faf8af43
    • Tobias Diedrich's avatar
      serial: 8250_pci: Add Realtek 816a and 816b · 68593a8e
      Tobias Diedrich authored
      commit 3c5a87be upstream.
      
      These serial ports are exposed by the OOB-management-engine on
      RealManage-enabled network cards (e.g. AMD DASH enabled systems using
      Realtek cards).
      
      Because these have 3 BARs, they fail the "num_iomem <= 1" check in
      serial_pci_guess_board.
      
      I've manually checked the two IOMEM regions and BAR 2 doesn't seem to
      respond to reads, but BAR 4 seems to be an MMIO version of the IO ports
      (untested).
      
      With this change, the ports are detected:
      0000:02:00.1: ttyS0 at I/O 0x2200 (irq = 82, base_baud = 115200) is a 16550A
      0000:02:00.2: ttyS1 at I/O 0x2100 (irq = 55, base_baud = 115200) is a 16550A
      
      lspci output:
      02:00.1 0700: 10ec:816a (rev 0e) (prog-if 02 [16550])
              Subsystem: 17aa:5082
              Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
              Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx-
              Interrupt: pin B routed to IRQ 82
              IOMMU group: 11
              Region 0: I/O ports at 2200 [size=256]
              Region 2: Memory at fd715000 (64-bit, non-prefetchable) [size=4K]
              Region 4: Memory at fd704000 (64-bit, non-prefetchable) [size=16K]
              Capabilities: [40] Power Management version 3
                      Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                      Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
              Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                      Address: 0000000000000000  Data: 0000
              Capabilities: [70] Express (v2) Endpoint, MSI 01
                      DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s unlimited, L1 <64us
                              ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W
                      DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                              RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
                              MaxPayload 128 bytes, MaxReadReq 512 bytes
                      DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
                      LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
                              ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
                      LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
                              ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                      LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
                              TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                      DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
                               10BitTagComp- 10BitTagReq- OBFF Via message/WAKE#, ExtFmt- EETLPPrefix-
                               EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                               FRS- TPHComp- ExtTPHComp-
                               AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                      DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled,
                               AtomicOpsCtl: ReqEn-
                      LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1-
                               EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest-
                               Retimer- 2Retimers- CrosslinkRes: unsupported
              Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
                      Vector table: BAR=4 offset=00000000
                      PBA: BAR=4 offset=00000800
              Capabilities: [d0] Vital Product Data
                      Not readable
              Capabilities: [100 v2] Advanced Error Reporting
                      UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                      UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                      UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                      CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                      CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                      AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                              MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                      HeaderLog: 00000000 00000000 00000000 00000000
              Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
              Capabilities: [170 v1] Latency Tolerance Reporting
                      Max snoop latency: 0ns
                      Max no snoop latency: 0ns
              Capabilities: [178 v1] L1 PM Substates
                      L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
                                PortCommonModeRestoreTime=150us PortTPowerOnTime=150us
                      L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                                 T_CommonMode=0us LTR1.2_Threshold=0ns
                      L1SubCtl2: T_PwrOn=10us
      02:00.2 0700: 10ec:816b (rev 0e)
      [...same...]
      Signed-off-by: default avatarTobias Diedrich <tobiasdiedrich@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200914173628.GA22508@yamamaya.is-a-geek.orgSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      68593a8e