1. 15 6月, 2019 40 次提交
    • A
      dmaengine: idma64: Use actual device for DMA transfers · 9fdcb04e
      Andy Shevchenko 提交于
      [ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
      
      Intel IOMMU, when enabled, tries to find the domain of the device,
      assuming it's a PCI one, during DMA operations, such as mapping or
      unmapping. Since we are splitting the actual PCI device to couple of
      children via MFD framework (see drivers/mfd/intel-lpss.c for details),
      the DMA device appears to be a platform one, and thus not an actual one
      that performs DMA. In a such situation IOMMU can't find or allocate
      a proper domain for its operations. As a result, all DMA operations are
      failed.
      
      In order to fix this, supply parent of the platform device
      to the DMA engine framework and fix filter functions accordingly.
      
      We may rely on the fact that parent is a real PCI device, because no
      other configuration is present in the wild.
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMark Brown <broonie@kernel.org>
      Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts]
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      9fdcb04e
    • B
      ice: Add missing case in print_link_msg for printing flow control · da00c89f
      Brett Creeley 提交于
      [ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ]
      
      Currently we aren't checking for the ICE_FC_NONE case for the current
      flow control mode. This is causing "Unknown" to be printed for the
      current flow control method if flow control is disabled. Fix this by
      adding the case for ICE_FC_NONE to print "None".
      Signed-off-by: NBrett Creeley <brett.creeley@intel.com>
      Signed-off-by: NAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      da00c89f
    • T
      gpio: gpio-omap: add check for off wake capable gpios · 456e3563
      Tony Lindgren 提交于
      [ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
      
      We are currently assuming all GPIOs are non-wakeup capable GPIOs as we
      not configuring the bank->non_wakeup_gpios like we used to earlier with
      platform_data.
      
      Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer
      while considering that later patches may want to configure SoC specific
      bank->non_wakeup_gpios for the GPIOs in wakeup domain.
      
      Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Keerthy <j-keerthy@ti.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
      Cc: Russell King <rmk+kernel@armlinux.org.uk>
      Cc: Tero Kristo <t-kristo@ti.com>
      Reported-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      456e3563
    • K
      PCI: xilinx: Check for __get_free_pages() failure · 47d281bb
      Kangjie Lu 提交于
      [ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
      
      If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer
      dereference.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NSteven Price <steven.price@arm.com>
      Reviewed-by: NMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      47d281bb
    • P
      block, bfq: increase idling for weight-raised queues · b5a185ee
      Paolo Valente 提交于
      [ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ]
      
      If a sync bfq_queue has a higher weight than some other queue, and
      remains temporarily empty while in service, then, to preserve the
      bandwidth share of the queue, it is necessary to plug I/O dispatching
      until a new request arrives for the queue. In addition, a timeout
      needs to be set, to avoid waiting for ever if the process associated
      with the queue has actually finished its I/O.
      
      Even with the above timeout, the device is however not fed with new
      I/O for a while, if the process has finished its I/O. If this happens
      often, then throughput drops and latencies grow. For this reason, the
      timeout is kept rather low: 8 ms is the current default.
      
      Unfortunately, such a low value may cause, on the opposite end, a
      violation of bandwidth guarantees for a process that happens to issue
      new I/O too late. The higher the system load, the higher the
      probability that this happens to some process. This is a problem in
      scenarios where service guarantees matter more than throughput. One
      important case are weight-raised queues, which need to be granted a
      very high fraction of the bandwidth.
      
      To address this issue, this commit lower-bounds the plugging timeout
      for weight-raised queues to 20 ms. This simple change provides
      relevant benefits. For example, on a PLEXTOR PX-256M5S, with which
      gnome-terminal starts in 0.6 seconds if there is no other I/O in
      progress, the same applications starts in
      - 0.8 seconds, instead of 1.2 seconds, if ten files are being read
        sequentially in parallel
      - 1 second, instead of 2 seconds, if, in parallel, five files are
        being read sequentially, and five more files are being written
        sequentially
      Tested-by: NHolger Hoffstätte <holger@applied-asynchrony.com>
      Tested-by: NOleksandr Natalenko <oleksandr@natalenko.name>
      Signed-off-by: NPaolo Valente <paolo.valente@linaro.org>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b5a185ee
    • K
      video: imsttfb: fix potential NULL pointer dereferences · e06d7a92
      Kangjie Lu 提交于
      [ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
      
      In case ioremap fails, the fix releases resources and returns
      -ENOMEM to avoid NULL pointer dereferences.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Finn Thain <fthain@telegraphics.com.au>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      [b.zolnierkie: minor patch summary fixup]
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      e06d7a92
    • K
      video: hgafb: fix potential NULL pointer dereference · 1f2611af
      Kangjie Lu 提交于
      [ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
      
      When ioremap fails, hga_vram should not be dereferenced. The fix
      check the failure to avoid NULL pointer dereference.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Cc: Aditya Pakki <pakki001@umn.edu>
      Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
      [b.zolnierkie: minor patch summary fixup]
      Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1f2611af
    • G
      scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags · 5957f6f5
      Giridhar Malavali 提交于
      [ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ]
      
      Driver maintains state machine for processing and completing switch
      commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the
      previous command is active or sent, in order for next GPSC command to
      advance the state machine.
      
      [mkp: commit desc typo]
      Signed-off-by: NGiridhar Malavali <gmalavali@marvell.com>
      Signed-off-by: NHimanshu Madhani <hmadhani@marvell.com>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5957f6f5
    • M
      PCI: rcar: Fix 64bit MSI message address handling · c2c7b6fe
      Marek Vasut 提交于
      [ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]
      
      The MSI message address in the RC address space can be 64 bit. The
      R-Car PCIe RC supports such a 64bit MSI message address as well.
      The code currently uses virt_to_phys(__get_free_pages()) to obtain
      a reserved page for the MSI message address, and the return value
      of which can be a 64 bit physical address on 64 bit system.
      
      However, the driver only programs PCIEMSIALR register with the bottom
      32 bits of the virt_to_phys(__get_free_pages()) return value and does
      not program the top 32 bits into PCIEMSIAUR, but rather programs the
      PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
      SoCs, however may fail on new 64 bit R-Car SoCs.
      
      Since from a PCIe controller perspective, an inbound MSI is a memory
      write to a special address (in case of this controller, defined by
      the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
      never hits the DRAM _and_ because allocation of an MSI by a PCIe card
      driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
      in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
      cause memory corruption or other issues.
      
      There is however the possibility that if virt_to_phys(__get_free_pages())
      returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
      to 0x0 _and_ if the system had physical RAM at the address matching the
      value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
      physical address matching the value of PCIEMSIALR and a remote write to
      such a buffer by a PCIe card would trigger a spurious MSI.
      
      Fixes: e015f88c ("PCI: rcar: Add support for R-Car H3 to pcie-rcar")
      Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Phil Edworthy <phil.edworthy@renesas.com>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: linux-renesas-soc@vger.kernel.org
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c2c7b6fe
    • K
      PCI: rcar: Fix a potential NULL pointer dereference · dd54e70c
      Kangjie Lu 提交于
      [ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
      
      In case __get_free_pages() fails and returns NULL, fix the return
      value to -ENOMEM and release resources to avoid dereferencing a
      NULL pointer.
      Signed-off-by: NKangjie Lu <kjlu@umn.edu>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: NUlrich Hecht <uli+renesas@fpond.eu>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      dd54e70c
    • P
      net: hns3: return 0 and print warning when hit duplicate MAC · 272f8c3d
      Peng Li 提交于
      [ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ]
      
      When set 2 same MAC to different function of one port, IMP
      will return error as the later one may modify the origin one.
      This will cause bond fail for 2 VFs of one port.
      
      Driver just print warning and return 0 with this patch, so
      if set same MAC address, it will return 0 but do not really
      configure HW.
      Signed-off-by: NPeng Li <lipeng321@huawei.com>
      Signed-off-by: NHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      272f8c3d
    • S
      power: supply: max14656: fix potential use-before-alloc · 5a286ced
      Sven Van Asbroeck 提交于
      [ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ]
      
      Call order on probe():
      - max14656_hw_init() enables interrupts on the chip
      - devm_request_irq() starts processing interrupts, isr
        could be called immediately
      -    isr: schedules delayed work (irq_work)
      -    irq_work: calls power_supply_changed()
      - devm_power_supply_register() registers the power supply
      
      Depending on timing, it's possible that power_supply_changed()
      is called on an unregistered power supply structure.
      
      Fix by registering the power supply before requesting the irq.
      
      Cc: Alexander Kurz <akurz@blala.de>
      Signed-off-by: NSven Van Asbroeck <TheSven73@gmail.com>
      Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      5a286ced
    • J
      platform/x86: intel_pmc_ipc: adding error handling · 901daed2
      Junxiao Chang 提交于
      [ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ]
      
      If punit or telemetry device initialization fails, pmc driver should
      unregister and return failure.
      
      This change is to fix a kernel panic when removing kernel module
      intel_pmc_ipc.
      
      Fixes: 48c19170 ("platform:x86: Add Intel telemetry platform device")
      Signed-off-by: NJunxiao Chang <junxiao.chang@intel.com>
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      901daed2
    • K
      ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it · 613752b3
      Kabir Sahane 提交于
      [ Upstream commit 72aff4ecf1cb85a3c6e6b42ccbda0bc631b090b3 ]
      
      This area is used to store keys by HSPPA in case of AM438x SOC. Leave it
      active.
      Signed-off-by: NKabir Sahane <x0153567@ti.com>
      Signed-off-by: NAndrew F. Davis <afd@ti.com>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      613752b3
    • N
      drm/amd/display: Use plane->color_space for dpp if specified · 668440f6
      Nicholas Kazlauskas 提交于
      [ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ]
      
      [Why]
      The input color space for the plane was previously ignored even if it
      was set.
      
      If a limited range YUV format was given to DC then the
      wrong color transformation matrix was being used since DC assumed that
      it was full range instead.
      
      [How]
      Respect the given color_space format for the plane if it isn't
      COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM
      didn't specify.
      Signed-off-by: NNicholas Kazlauskas <nicholas.kazlauskas@amd.com>
      Reviewed-by: NSun peng Li <Sunpeng.Li@amd.com>
      Acked-by: NAric Cyr <Aric.Cyr@amd.com>
      Acked-by: NLeo Li <sunpeng.li@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      668440f6
    • T
      PCI: rpadlpar: Fix leaked device_node references in add/remove paths · 671fc900
      Tyrel Datwyler 提交于
      [ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ]
      
      The find_dlpar_node() helper returns a device node with its reference
      incremented.  Both the add and remove paths use this helper for find the
      appropriate node, but fail to release the reference when done.
      
      Annotate the find_dlpar_node() helper with a comment about the incremented
      reference count and call of_node_put() on the obtained device_node in the
      add and remove paths.  Also, fixup a reference leak in the find_vio_slot()
      helper where we fail to call of_node_put() on the vdevice node after we
      iterate over its children.
      Signed-off-by: NTyrel Datwyler <tyreld@linux.vnet.ibm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      671fc900
    • A
      ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA · b531acbd
      Andrey Smirnov 提交于
      [ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality(this at least
      breaks RAVE SP serdev driver on RDU2). Fix the code to specify
      IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect
      clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Tested-by: NAdam Ford <aford173@gmail.com>
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b531acbd
    • A
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA · 584cabc6
      Andrey Smirnov 提交于
      [ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      584cabc6
    • A
      ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA · 02936545
      Andrey Smirnov 提交于
      [ Upstream commit 7b3132ecefdd1fcdf6b86e62021d0e55ea8034db ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6UL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      02936545
    • A
      ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA · 36a7fda0
      Andrey Smirnov 提交于
      [ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      36a7fda0
    • A
      ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA · c84911bb
      Andrey Smirnov 提交于
      [ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      c84911bb
    • A
      ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA · a2e661f9
      Andrey Smirnov 提交于
      [ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a2e661f9
    • A
      ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 461f4183
      Andrey Smirnov 提交于
      [ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      461f4183
    • A
      ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 998860d0
      Andrey Smirnov 提交于
      [ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      998860d0
    • A
      ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA · 70465bbb
      Andrey Smirnov 提交于
      [ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ]
      
      Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb"
      clock to determine if it needs to configure the IP block as operating
      at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both
      clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that
      ratio is 1:1 which results in broken SDMA funtionality. Fix the code
      to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting
      incorrect clock ratio.
      Signed-off-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Cc: Angus Ainslie (Purism) <angus@akkea.ca>
      Cc: Chris Healy <cphealy@gmail.com>
      Cc: Lucas Stach <l.stach@pengutronix.de>
      Cc: Fabio Estevam <fabio.estevam@nxp.com>
      Cc: Shawn Guo <shawnguo@kernel.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NShawn Guo <shawnguo@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      70465bbb
    • D
      soc: rockchip: Set the proper PWM for rk3288 · 57f89084
      Douglas Anderson 提交于
      [ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ]
      
      The rk3288 SoC has two PWM implementations available, the "old"
      implementation and the "new" one.  You can switch between the two of
      them by flipping a bit in the grf.
      
      The "old" implementation is the default at chip power up but isn't the
      one that's officially supposed to be used.  ...and, in fact, the
      driver that gets selected in Linux using the rk3288 device tree only
      supports the "new" implementation.
      
      Long ago I tried to get a switch to the right IP block landed in the
      PWM driver (search for "rk3288: Switch to use the proper PWM IP") but
      that got rejected.  In the mean time the grf has grown a full-fledged
      driver that already sets other random bits like this.  That means we
      can now get the fix landed.
      
      For those wondering how things could have possibly worked for the last
      4.5 years, folks have mostly been relying on the bootloader to set
      this bit.  ...but occasionally folks have pointed back to my old patch
      series [1] in downstream kernels.
      
      [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1391597.htmlSigned-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      57f89084
    • D
      clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288 · b1659486
      Douglas Anderson 提交于
      [ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
      
      Experimentally it can be seen that going into deep sleep (specifically
      setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
      appears to fail unless "aclk_dmac1" is on.  The failure is that the
      system never signals that it made it into suspend on the GLOBAL_PWROFF
      pin and it just hangs.
      
      NOTE that it's confirmed that it's the actual suspend that fails, not
      one of the earlier calls to read/write registers.  Specifically if you
      comment out the "PMU_GLOBAL_INT_DISABLE" setting in
      rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
      rockchip_lpmode_enter() then you can exercise the whole suspend path
      without any crashing.
      
      This is currently not a problem with suspend upstream because there is
      no current way to exercise the deep suspend code.  However, anyone
      trying to make it work will run into this issue.
      
      This was not a problem on shipping rk3288-based Chromebooks because
      those devices all ran on an old kernel based on 3.14.  On that kernel
      "aclk_dmac1" appears to be left on all the time.
      
      There are several ways to skin this problem.
      
      A) We could add "aclk_dmac1" to the list of critical clocks and that
      apperas to work, but presumably that wastes power.
      
      B) We could keep a list of "struct clk" objects to enable at suspend
      time in clk-rk3288.c and use the standard clock APIs.
      
      C) We could make the rk3288-pmu driver keep a list of clocks to enable
      at suspend time.  Presumably this would require a dts and bindings
      change.
      
      D) We could just whack the clock on in the existing syscore suspend
      function where we whack a bunch of other clocks.  This is particularly
      easy because we know for sure that the clock's only parent
      ("aclk_cpu") is a critical clock so we don't need to do anything more
      than ungate it.
      
      In this case I have chosen D) because it seemed like the least work,
      but any of the other options would presumably also work fine.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NElaine Zhang <zhangqing@rock-chips.com>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b1659486
    • N
      soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher · 8e9dd864
      Nathan Chancellor 提交于
      [ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
      
      When building with -Wsometimes-uninitialized, Clang warns:
      
      drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is
      used uninitialized whenever '||' condition is true
      [-Werror,-Wsometimes-uninitialized]
      
      If pwrap_write returns non-zero, pwrap_read will not be called to
      initialize rdata, meaning that we will use some random uninitialized
      stack value in our print statement. Zero initialize rdata in case this
      happens.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/401Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      8e9dd864
    • K
      PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64 · f7c0e670
      Kishon Vijay Abraham I 提交于
      [ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]
      
      hook_fault_code() is an ARM32 specific API for hooking into data abort.
      
      AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as
      arch) rely on pci-keystone.c but on them the enumeration of a
      non-present BDF does not trigger a bus error, so the fixup exception
      provided by calling hook_fault_code() is not needed and can be guarded
      with CONFIG_ARM.
      Signed-off-by: NKishon Vijay Abraham I <kishon@ti.com>
      [lorenzo.pieralisi@arm.com: commit log]
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f7c0e670
    • E
      platform/chrome: cros_ec_proto: check for NULL transfer function · a357310a
      Enrico Granata 提交于
      [ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
      
      As new transfer mechanisms are added to the EC codebase, they may
      not support v2 of the EC protocol.
      
      If the v3 initial handshake transfer fails, the kernel will try
      and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer
      will be NULL, and the code will end up causing a kernel panic.
      
      Add a check for NULL before calling the transfer function, along
      with a helpful comment explaining how one might end up in this
      situation.
      Signed-off-by: NEnrico Granata <egranata@chromium.org>
      Reviewed-by: NJett Rink <jettrink@chromium.org>
      Signed-off-by: NEnric Balletbo i Serra <enric.balletbo@collabora.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      a357310a
    • A
      i40e: Queues are reserved despite "Invalid argument" error · b78a9b28
      Adam Ludkiewicz 提交于
      [ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ]
      
      Added a new local variable in the i40e_setup_tc function named
      old_queue_pairs so num_queue_pairs can be restored to the correct
      value in case configuring queue channels fails. Additionally, moved
      the exit label in the i40e_setup_tc function so the if (need_reset)
      block can be executed.
      Also, fixed data packing in the i40e_setup_tc function.
      Signed-off-by: NAdam Ludkiewicz <adam.ludkiewicz@intel.com>
      Tested-by: NAndrew Bowers <andrewx.bowers@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b78a9b28
    • W
      x86/PCI: Fix PCI IRQ routing table memory leak · aeb743db
      Wenwen Wang 提交于
      [ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
      
      In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first
      found through pirq_find_routing_table().  If the table is not found and
      CONFIG_PCI_BIOS is defined, the table is then allocated in
      pcibios_get_irq_routing_table() using kmalloc().  Later, if the I/O APIC is
      used, this table is actually not used.  In that case, the allocated table
      is not freed, which is a memory leak.
      
      Free the allocated table if it is not used.
      Signed-off-by: NWenwen Wang <wang6495@umn.edu>
      [bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to
      use the irq_routing_table local variable name he suggested]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      aeb743db
    • M
      net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending · 47e6a354
      Mika Westerberg 提交于
      [ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ]
      
      The XDomain protocol messages may start as soon as Thunderbolt control
      channel is started. This means that if the other host starts sending
      ThunderboltIP packets early enough they will be passed to the network
      driver which then gets confused because its resume hook is not called
      yet.
      
      Fix this by unregistering the ThunderboltIP protocol handler when
      suspending and registering it back on resume.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      47e6a354
    • W
      switchtec: Fix unintended mask of MRPC event · 31aa2a7a
      Wesley Sheng 提交于
      [ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ]
      
      When running application tool switchtec-user's `firmware update` and `event
      wait` commands concurrently, sometimes the firmware update speed reduced
      significantly.
      
      It is because when the MRPC event happened after MRPC event occurrence
      check but before the event mask loop reaches its header register in event
      ISR, the MRPC event would be masked unintentionally.  Since there's no
      chance to enable it again except for a module reload, all the following
      MRPC execution completion checks time out.
      
      Fix this bug by skipping the mask operation for MRPC event in event ISR,
      same as what we already do for LINK event.
      
      Fixes: 52eabba5 ("switchtec: Add IOCTLs to the Switchtec driver")
      Signed-off-by: NWesley Sheng <wesley.sheng@microchip.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      31aa2a7a
    • W
      iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel · 4b19a45e
      Will Deacon 提交于
      [ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ]
      
      Disabling the SMMU when probing from within a kdump kernel so that all
      incoming transactions are terminated can prevent the core of the crashed
      kernel from being transferred off the machine if all I/O devices are
      behind the SMMU.
      
      Instead, continue to probe the SMMU after it is disabled so that we can
      reinitialise it entirely and re-attach the DMA masters as they are reset.
      Since the kdump kernel may not have drivers for all of the active DMA
      masters, we suppress fault reporting to avoid spamming the console and
      swamping the IRQ threads.
      Reported-by: N"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
      Tested-by: N"Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
      Tested-by: NBhupesh Sharma <bhsharma@redhat.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      4b19a45e
    • F
      vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING" · f7883f9b
      Farhan Ali 提交于
      [ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ]
      
      vfio_dev_present() which is the condition to
      wait_event_interruptible_timeout(), will call vfio_group_get_device
      and try to acquire the mutex group->device_lock.
      
      wait_event_interruptible_timeout() will set the state of the current
      task to TASK_INTERRUPTIBLE, before doing the condition check. This
      means that we will try to acquire the mutex while already in a
      sleeping state. The scheduler warns us by giving the following
      warning:
      
      [ 4050.264464] ------------[ cut here ]------------
      [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188
      [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90
      ....
      
       4050.264756] Call Trace:
      [ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90)
      [ 4050.264774]  [<0000000000b97edc>] __mutex_lock+0x44/0x8c0
      [ 4050.264782]  [<0000000000b9878a>] mutex_lock_nested+0x32/0x40
      [ 4050.264793]  [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio]
      [ 4050.264803]  [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio]
      [ 4050.264813]  [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev]
      [ 4050.264825]  [<00000000008e01b0>] device_release_driver_internal+0x168/0x268
      [ 4050.264834]  [<00000000008de692>] bus_remove_device+0x162/0x190
      [ 4050.264843]  [<00000000008daf42>] device_del+0x1e2/0x368
      [ 4050.264851]  [<00000000008db12c>] device_unregister+0x64/0x88
      [ 4050.264862]  [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev]
      [ 4050.264872]  [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev]
      [ 4050.264881]  [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
      [ 4050.264890]  [<00000000003c1530>] __vfs_write+0x38/0x1a8
      [ 4050.264899]  [<00000000003c187c>] vfs_write+0xb4/0x198
      [ 4050.264908]  [<00000000003c1af2>] ksys_write+0x5a/0xb0
      [ 4050.264916]  [<0000000000b9e270>] system_call+0xdc/0x2d8
      [ 4050.264925] 4 locks held by sh/35924:
      [ 4050.264933]  #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198
      [ 4050.264948]  #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8
      [ 4050.264963]  #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150
      [ 4050.264979]  #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268
      [ 4050.264993] Last Breaking-Event-Address:
      [ 4050.265002]  [<000000000017bbaa>] __might_sleep+0x72/0x90
      [ 4050.265010] irq event stamp: 7039
      [ 4050.265020] hardirqs last  enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740
      [ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740
      [ 4050.265040] softirqs last  enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100
      [ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100
      [ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]---
      
      Let's fix this as described in the article
      https://lwn.net/Articles/628628/.
      Signed-off-by: NFarhan Ali <alifm@linux.ibm.com>
      [remove now redundant vfio_dev_present()]
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      f7883f9b
    • A
      nfsd: avoid uninitialized variable warning · 806e8395
      Arnd Bergmann 提交于
      [ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ]
      
      clang warns that 'contextlen' may be accessed without an initialization:
      
      fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized]
                                                                      contextlen);
                                                                      ^~~~~~~~~~
      fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning
              int contextlen;
                            ^
                             = 0
      
      Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is
      set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled.
      Adding another #ifdef like the other two in this function
      avoids the warning.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      806e8395
    • J
      nfsd: allow fh_want_write to be called twice · b4330e4a
      J. Bruce Fields 提交于
      [ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
      
      A fuzzer recently triggered lockdep warnings about potential sb_writers
      deadlocks caused by fh_want_write().
      
      Looks like we aren't careful to pair each fh_want_write() with an
      fh_drop_write().
      
      It's not normally a problem since fh_put() will call fh_drop_write() for
      us.  And was OK for NFSv3 where we'd do one operation that might call
      fh_want_write(), and then put the filehandle.
      
      But an NFSv4 protocol fuzzer can do weird things like call unlink twice
      in a compound, and then we get into trouble.
      
      I'm a little worried about this approach of just leaving everything to
      fh_put().  But I think there are probably a lot of
      fh_want_write()/fh_drop_write() imbalances so for now I think we need it
      to be more forgiving.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      b4330e4a
    • K
      fuse: retrieve: cap requested size to negotiated max_write · ae35c325
      Kirill Smelkov 提交于
      [ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
      
      FUSE filesystem server and kernel client negotiate during initialization
      phase, what should be the maximum write size the client will ever issue.
      Correspondingly the filesystem server then queues sys_read calls to read
      requests with buffer capacity large enough to carry request header + that
      max_write bytes. A filesystem server is free to set its max_write in
      anywhere in the range between [1*page, fc->max_pages*page]. In particular
      go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages
      corresponds to 128K. Libfuse also allows users to configure max_write, but
      by default presets it to possible maximum.
      
      If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we
      allow to retrieve more than max_write bytes, corresponding prepared
      NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the
      filesystem server, in full correspondence with server/client contract, will
      be only queuing sys_read with ~max_write buffer capacity, and
      fuse_dev_do_read throws away requests that cannot fit into server request
      buffer. In turn the filesystem server could get stuck waiting indefinitely
      for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is
      understood by clients as that NOTIFY_REPLY was queued and will be sent
      back.
      
      Cap requested size to negotiate max_write to avoid the problem.  This
      aligns with the way NOTIFY_RETRIEVE handler works, which already
      unconditionally caps requested retrieve size to fuse_conn->max_pages.  This
      way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than
      was originally requested.
      
      Please see [1] for context where the problem of stuck filesystem was hit
      for real, how the situation was traced and for more involving patch that
      did not make it into the tree.
      
      [1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
      [2] https://github.com/hanwen/go-fuseSigned-off-by: NKirill Smelkov <kirr@nexedi.com>
      Cc: Han-Wen Nienhuys <hanwen@google.com>
      Cc: Jakob Unterwurzacher <jakobunt@gmail.com>
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      ae35c325
    • C
      nvmem: sunxi_sid: Support SID on A83T and H5 · 1c2e9746
      Chen-Yu Tsai 提交于
      [ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ]
      
      The device tree binding already lists compatible strings for these two
      SoCs. They don't have the defect as seen on the H3, and the size and
      register layout is the same as the A64. Furthermore, the driver does
      not include nvmem cell definitions.
      
      Add support for these two compatible strings, re-using the config for
      the A64.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      1c2e9746