]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 6.1
authorSasha Levin <sashal@kernel.org>
Mon, 4 Mar 2024 12:22:14 +0000 (07:22 -0500)
committerSasha Levin <sashal@kernel.org>
Mon, 4 Mar 2024 12:22:14 +0000 (07:22 -0500)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-6.1/block-define-bvec_iter-as-__packed-__aligned-4.patch [new file with mode: 0644]
queue-6.1/gpio-74x164-enable-output-pins-after-registers-are-r.patch [new file with mode: 0644]
queue-6.1/gpio-fix-resource-unwinding-order-in-error-path.patch [new file with mode: 0644]
queue-6.1/gpiolib-fix-the-error-path-order-in-gpiochip_add_dat.patch [new file with mode: 0644]
queue-6.1/phy-freescale-phy-fsl-imx8-mipi-dphy-fix-alias-name-.patch [new file with mode: 0644]
queue-6.1/powerpc-pseries-iommu-iommu-table-is-not-initialized.patch [new file with mode: 0644]
queue-6.1/series

diff --git a/queue-6.1/block-define-bvec_iter-as-__packed-__aligned-4.patch b/queue-6.1/block-define-bvec_iter-as-__packed-__aligned-4.patch
new file mode 100644 (file)
index 0000000..0d6e3e8
--- /dev/null
@@ -0,0 +1,44 @@
+From daac896f818d8470fef2f427dc925f0e3b6a9e23 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 25 Feb 2024 11:01:41 +0800
+Subject: block: define bvec_iter as __packed __aligned(4)
+
+From: Ming Lei <ming.lei@redhat.com>
+
+[ Upstream commit 7838b4656110d950afdd92a081cc0f33e23e0ea8 ]
+
+In commit 19416123ab3e ("block: define 'struct bvec_iter' as packed"),
+what we need is to save the 4byte padding, and avoid `bio` to spread on
+one extra cache line.
+
+It is enough to define it as '__packed __aligned(4)', as '__packed'
+alone means byte aligned, and can cause compiler to generate horrible
+code on architectures that don't support unaligned access in case that
+bvec_iter is embedded in other structures.
+
+Cc: Mikulas Patocka <mpatocka@redhat.com>
+Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
+Fixes: 19416123ab3e ("block: define 'struct bvec_iter' as packed")
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ include/linux/bvec.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/include/linux/bvec.h b/include/linux/bvec.h
+index 9e3dac51eb26b..d4dbaae8b5218 100644
+--- a/include/linux/bvec.h
++++ b/include/linux/bvec.h
+@@ -59,7 +59,7 @@ struct bvec_iter {
+       unsigned int            bi_bvec_done;   /* number of bytes completed in
+                                                  current bvec */
+-} __packed;
++} __packed __aligned(4);
+ struct bvec_iter_all {
+       struct bio_vec  bv;
+-- 
+2.43.0
+
diff --git a/queue-6.1/gpio-74x164-enable-output-pins-after-registers-are-r.patch b/queue-6.1/gpio-74x164-enable-output-pins-after-registers-are-r.patch
new file mode 100644 (file)
index 0000000..dcc6678
--- /dev/null
@@ -0,0 +1,57 @@
+From c54ac948e9e4bc3f77126ee36191307299106e4f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 1 Mar 2024 09:12:04 +0200
+Subject: gpio: 74x164: Enable output pins after registers are reset
+
+From: Arturas Moskvinas <arturas.moskvinas@gmail.com>
+
+[ Upstream commit 530b1dbd97846b110ea8a94c7cc903eca21786e5 ]
+
+Chip outputs are enabled[1] before actual reset is performed[2] which might
+cause pin output value to flip flop if previous pin value was set to 1.
+Fix that behavior by making sure chip is fully reset before all outputs are
+enabled.
+
+Flip-flop can be noticed when module is removed and inserted again and one of
+the pins was changed to 1 before removal. 100 microsecond flipping is
+noticeable on oscilloscope (100khz SPI bus).
+
+For a properly reset chip - output is enabled around 100 microseconds (on 100khz
+SPI bus) later during probing process hence should be irrelevant behavioral
+change.
+
+Fixes: 7ebc194d0fd4 (gpio: 74x164: Introduce 'enable-gpios' property)
+Link: https://elixir.bootlin.com/linux/v6.7.4/source/drivers/gpio/gpio-74x164.c#L130 [1]
+Link: https://elixir.bootlin.com/linux/v6.7.4/source/drivers/gpio/gpio-74x164.c#L150 [2]
+Signed-off-by: Arturas Moskvinas <arturas.moskvinas@gmail.com>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpio-74x164.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpio/gpio-74x164.c b/drivers/gpio/gpio-74x164.c
+index e00c333105170..753e7be039e4d 100644
+--- a/drivers/gpio/gpio-74x164.c
++++ b/drivers/gpio/gpio-74x164.c
+@@ -127,8 +127,6 @@ static int gen_74x164_probe(struct spi_device *spi)
+       if (IS_ERR(chip->gpiod_oe))
+               return PTR_ERR(chip->gpiod_oe);
+-      gpiod_set_value_cansleep(chip->gpiod_oe, 1);
+-
+       spi_set_drvdata(spi, chip);
+       chip->gpio_chip.label = spi->modalias;
+@@ -153,6 +151,8 @@ static int gen_74x164_probe(struct spi_device *spi)
+               goto exit_destroy;
+       }
++      gpiod_set_value_cansleep(chip->gpiod_oe, 1);
++
+       ret = gpiochip_add_data(&chip->gpio_chip, chip);
+       if (!ret)
+               return 0;
+-- 
+2.43.0
+
diff --git a/queue-6.1/gpio-fix-resource-unwinding-order-in-error-path.patch b/queue-6.1/gpio-fix-resource-unwinding-order-in-error-path.patch
new file mode 100644 (file)
index 0000000..a0f9d9a
--- /dev/null
@@ -0,0 +1,54 @@
+From dcce9cdbc7cdc9c08c7b8ef16dad80c75f020e63 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 29 Feb 2024 18:25:49 +0100
+Subject: gpio: fix resource unwinding order in error path
+
+From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+
+[ Upstream commit ec5c54a9d3c4f9c15e647b049fea401ee5258696 ]
+
+Hogs are added *after* ACPI so should be removed *before* in error path.
+
+Fixes: a411e81e61df ("gpiolib: add hogs support for machine code")
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpiolib.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
+index f646df7f1b41a..9d8c783124033 100644
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -784,11 +784,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
+       ret = gpiochip_irqchip_init_valid_mask(gc);
+       if (ret)
+-              goto err_remove_acpi_chip;
++              goto err_free_hogs;
+       ret = gpiochip_irqchip_init_hw(gc);
+       if (ret)
+-              goto err_remove_acpi_chip;
++              goto err_remove_irqchip_mask;
+       ret = gpiochip_add_irqchip(gc, lock_key, request_key);
+       if (ret)
+@@ -813,11 +813,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
+       gpiochip_irqchip_remove(gc);
+ err_remove_irqchip_mask:
+       gpiochip_irqchip_free_valid_mask(gc);
+-err_remove_acpi_chip:
++err_free_hogs:
++      gpiochip_free_hogs(gc);
+       acpi_gpiochip_remove(gc);
+       gpiochip_remove_pin_ranges(gc);
+ err_remove_of_chip:
+-      gpiochip_free_hogs(gc);
+       of_gpiochip_remove(gc);
+ err_free_gpiochip_mask:
+       gpiochip_free_valid_mask(gc);
+-- 
+2.43.0
+
diff --git a/queue-6.1/gpiolib-fix-the-error-path-order-in-gpiochip_add_dat.patch b/queue-6.1/gpiolib-fix-the-error-path-order-in-gpiochip_add_dat.patch
new file mode 100644 (file)
index 0000000..b59223d
--- /dev/null
@@ -0,0 +1,40 @@
+From 58de69af71508e3a0a45c88e36d20ed1dc7eebcd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 21 Feb 2024 21:28:46 +0200
+Subject: gpiolib: Fix the error path order in gpiochip_add_data_with_key()
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+[ Upstream commit e4aec4daa8c009057b5e063db1b7322252c92dc8 ]
+
+After shuffling the code, error path wasn't updated correctly.
+Fix it here.
+
+Fixes: 2f4133bb5f14 ("gpiolib: No need to call gpiochip_remove_pin_ranges() twice")
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpio/gpiolib.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
+index 6d3e3454a6ed6..f646df7f1b41a 100644
+--- a/drivers/gpio/gpiolib.c
++++ b/drivers/gpio/gpiolib.c
+@@ -815,11 +815,11 @@ int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
+       gpiochip_irqchip_free_valid_mask(gc);
+ err_remove_acpi_chip:
+       acpi_gpiochip_remove(gc);
++      gpiochip_remove_pin_ranges(gc);
+ err_remove_of_chip:
+       gpiochip_free_hogs(gc);
+       of_gpiochip_remove(gc);
+ err_free_gpiochip_mask:
+-      gpiochip_remove_pin_ranges(gc);
+       gpiochip_free_valid_mask(gc);
+       if (gdev->dev.release) {
+               /* release() has been registered by gpiochip_setup_dev() */
+-- 
+2.43.0
+
diff --git a/queue-6.1/phy-freescale-phy-fsl-imx8-mipi-dphy-fix-alias-name-.patch b/queue-6.1/phy-freescale-phy-fsl-imx8-mipi-dphy-fix-alias-name-.patch
new file mode 100644 (file)
index 0000000..6e0185b
--- /dev/null
@@ -0,0 +1,38 @@
+From 720276b8d8ee8dbe90303f0128002c7f785f9aca Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Jan 2024 10:33:43 +0100
+Subject: phy: freescale: phy-fsl-imx8-mipi-dphy: Fix alias name to use dashes
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+[ Upstream commit 7936378cb6d87073163130e1e1fc1e5f76a597cf ]
+
+Devicetree spec lists only dashes as valid characters for alias names.
+Table 3.2: Valid characters for alias names, Devicee Specification,
+Release v0.4
+
+Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
+Fixes: 3fbae284887de ("phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support")
+Link: https://lore.kernel.org/r/20240110093343.468810-1-alexander.stein@ew.tq-group.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+index e625b32889bfc..0928a526e2ab3 100644
+--- a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
++++ b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
+@@ -706,7 +706,7 @@ static int mixel_dphy_probe(struct platform_device *pdev)
+                       return ret;
+               }
+-              priv->id = of_alias_get_id(np, "mipi_dphy");
++              priv->id = of_alias_get_id(np, "mipi-dphy");
+               if (priv->id < 0) {
+                       dev_err(dev, "Failed to get phy node alias id: %d\n",
+                               priv->id);
+-- 
+2.43.0
+
diff --git a/queue-6.1/powerpc-pseries-iommu-iommu-table-is-not-initialized.patch b/queue-6.1/powerpc-pseries-iommu-iommu-table-is-not-initialized.patch
new file mode 100644 (file)
index 0000000..7f64b39
--- /dev/null
@@ -0,0 +1,334 @@
+From e02c865dba14894f44dee1a52a08cfae29a06d95 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 25 Jan 2024 14:30:17 -0600
+Subject: powerpc/pseries/iommu: IOMMU table is not initialized for kdump over
+ SR-IOV
+
+From: Gaurav Batra <gbatra@linux.vnet.ibm.com>
+
+[ Upstream commit 09a3c1e46142199adcee372a420b024b4fc61051 ]
+
+When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due
+to NULL pointer exception:
+
+  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)
+  BUG: Kernel NULL pointer dereference on read at 0x00000000
+  Faulting instruction address: 0xc000000020847ad4
+  Oops: Kernel access of bad area, sig: 11 [#1]
+  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
+  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop
+  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12
+  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries
+  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c
+  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)
+  MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 48288244  XER: 00000008
+  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1
+  ...
+  NIP _find_next_zero_bit+0x24/0x110
+  LR  bitmap_find_next_zero_area_off+0x5c/0xe0
+  Call Trace:
+    dev_printk_emit+0x38/0x48 (unreliable)
+    iommu_area_alloc+0xc4/0x180
+    iommu_range_alloc+0x1e8/0x580
+    iommu_alloc+0x60/0x130
+    iommu_alloc_coherent+0x158/0x2b0
+    dma_iommu_alloc_coherent+0x3c/0x50
+    dma_alloc_attrs+0x170/0x1f0
+    mlx5_cmd_init+0xc0/0x760 [mlx5_core]
+    mlx5_function_setup+0xf0/0x510 [mlx5_core]
+    mlx5_init_one+0x84/0x210 [mlx5_core]
+    probe_one+0x118/0x2c0 [mlx5_core]
+    local_pci_probe+0x68/0x110
+    pci_call_probe+0x68/0x200
+    pci_device_probe+0xbc/0x1a0
+    really_probe+0x104/0x540
+    __driver_probe_device+0xb4/0x230
+    driver_probe_device+0x54/0x130
+    __driver_attach+0x158/0x2b0
+    bus_for_each_dev+0xa8/0x130
+    driver_attach+0x34/0x50
+    bus_add_driver+0x16c/0x300
+    driver_register+0xa4/0x1b0
+    __pci_register_driver+0x68/0x80
+    mlx5_init+0xb8/0x100 [mlx5_core]
+    do_one_initcall+0x60/0x300
+    do_init_module+0x7c/0x2b0
+
+At the time of LPAR dump, before kexec hands over control to kdump
+kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.
+For the SR-IOV case, default DMA window "ibm,dma-window" is removed from
+the FDT and DDW added, for the device.
+
+Now, kexec hands over control to the kdump kernel.
+
+When the kdump kernel initializes, PCI busses are scanned and IOMMU
+group/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV
+case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba,
+fixes the path where memory is pre-mapped (direct mapped) to the DDW.
+When TCEs are direct mapped, there is no need to initialize IOMMU
+tables.
+
+iommu_table_setparms_lpar() only considers "ibm,dma-window" property
+when initiallizing IOMMU table. In the scenario where TCEs are
+dynamically allocated for SR-IOV, newly created IOMMU table is not
+initialized. Later, when the device driver tries to enter TCEs for the
+SR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().
+
+The fix is to initialize the IOMMU table with DDW property stored in the
+FDT. There are 2 points to remember:
+
+       1. For the dedicated adapter, kdump kernel would encounter both
+          default and DDW in FDT. In this case, DDW property is used to
+          initialize the IOMMU table.
+
+       2. A DDW could be direct or dynamic mapped. kdump kernel would
+          initialize IOMMU table and mark the existing DDW as
+          "dynamic". This works fine since, at the time of table
+          initialization, iommu_table_clear() makes some space in the
+          DDW, for some predefined number of TCEs which are needed for
+          kdump to succeed.
+
+Fixes: b1fc44eaa9ba ("pseries/iommu/ddw: Fix kdump to work in absence of ibm,dma-window")
+Signed-off-by: Gaurav Batra <gbatra@linux.vnet.ibm.com>
+Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://msgid.link/20240125203017.61014-1-gbatra@linux.ibm.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/pseries/iommu.c | 156 +++++++++++++++++--------
+ 1 file changed, 105 insertions(+), 51 deletions(-)
+
+diff --git a/arch/powerpc/platforms/pseries/iommu.c b/arch/powerpc/platforms/pseries/iommu.c
+index 97b026130c71b..1e5f083cdb720 100644
+--- a/arch/powerpc/platforms/pseries/iommu.c
++++ b/arch/powerpc/platforms/pseries/iommu.c
+@@ -569,29 +569,6 @@ static void iommu_table_setparms(struct pci_controller *phb,
+ struct iommu_table_ops iommu_table_lpar_multi_ops;
+-/*
+- * iommu_table_setparms_lpar
+- *
+- * Function: On pSeries LPAR systems, return TCE table info, given a pci bus.
+- */
+-static void iommu_table_setparms_lpar(struct pci_controller *phb,
+-                                    struct device_node *dn,
+-                                    struct iommu_table *tbl,
+-                                    struct iommu_table_group *table_group,
+-                                    const __be32 *dma_window)
+-{
+-      unsigned long offset, size, liobn;
+-
+-      of_parse_dma_window(dn, dma_window, &liobn, &offset, &size);
+-
+-      iommu_table_setparms_common(tbl, phb->bus->number, liobn, offset, size, IOMMU_PAGE_SHIFT_4K, NULL,
+-                                  &iommu_table_lpar_multi_ops);
+-
+-
+-      table_group->tce32_start = offset;
+-      table_group->tce32_size = size;
+-}
+-
+ struct iommu_table_ops iommu_table_pseries_ops = {
+       .set = tce_build_pSeries,
+       .clear = tce_free_pSeries,
+@@ -719,26 +696,71 @@ struct iommu_table_ops iommu_table_lpar_multi_ops = {
+  * dynamic 64bit DMA window, walking up the device tree.
+  */
+ static struct device_node *pci_dma_find(struct device_node *dn,
+-                                      const __be32 **dma_window)
++                                      struct dynamic_dma_window_prop *prop)
+ {
+-      const __be32 *dw = NULL;
++      const __be32 *default_prop = NULL;
++      const __be32 *ddw_prop = NULL;
++      struct device_node *rdn = NULL;
++      bool default_win = false, ddw_win = false;
+       for ( ; dn && PCI_DN(dn); dn = dn->parent) {
+-              dw = of_get_property(dn, "ibm,dma-window", NULL);
+-              if (dw) {
+-                      if (dma_window)
+-                              *dma_window = dw;
+-                      return dn;
++              default_prop = of_get_property(dn, "ibm,dma-window", NULL);
++              if (default_prop) {
++                      rdn = dn;
++                      default_win = true;
++              }
++              ddw_prop = of_get_property(dn, DIRECT64_PROPNAME, NULL);
++              if (ddw_prop) {
++                      rdn = dn;
++                      ddw_win = true;
++                      break;
++              }
++              ddw_prop = of_get_property(dn, DMA64_PROPNAME, NULL);
++              if (ddw_prop) {
++                      rdn = dn;
++                      ddw_win = true;
++                      break;
+               }
+-              dw = of_get_property(dn, DIRECT64_PROPNAME, NULL);
+-              if (dw)
+-                      return dn;
+-              dw = of_get_property(dn, DMA64_PROPNAME, NULL);
+-              if (dw)
+-                      return dn;
++
++              /* At least found default window, which is the case for normal boot */
++              if (default_win)
++                      break;
+       }
+-      return NULL;
++      /* For PCI devices there will always be a DMA window, either on the device
++       * or parent bus
++       */
++      WARN_ON(!(default_win | ddw_win));
++
++      /* caller doesn't want to get DMA window property */
++      if (!prop)
++              return rdn;
++
++      /* parse DMA window property. During normal system boot, only default
++       * DMA window is passed in OF. But, for kdump, a dedicated adapter might
++       * have both default and DDW in FDT. In this scenario, DDW takes precedence
++       * over default window.
++       */
++      if (ddw_win) {
++              struct dynamic_dma_window_prop *p;
++
++              p = (struct dynamic_dma_window_prop *)ddw_prop;
++              prop->liobn = p->liobn;
++              prop->dma_base = p->dma_base;
++              prop->tce_shift = p->tce_shift;
++              prop->window_shift = p->window_shift;
++      } else if (default_win) {
++              unsigned long offset, size, liobn;
++
++              of_parse_dma_window(rdn, default_prop, &liobn, &offset, &size);
++
++              prop->liobn = cpu_to_be32((u32)liobn);
++              prop->dma_base = cpu_to_be64(offset);
++              prop->tce_shift = cpu_to_be32(IOMMU_PAGE_SHIFT_4K);
++              prop->window_shift = cpu_to_be32(order_base_2(size));
++      }
++
++      return rdn;
+ }
+ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)
+@@ -746,17 +768,20 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)
+       struct iommu_table *tbl;
+       struct device_node *dn, *pdn;
+       struct pci_dn *ppci;
+-      const __be32 *dma_window = NULL;
++      struct dynamic_dma_window_prop prop;
+       dn = pci_bus_to_OF_node(bus);
+       pr_debug("pci_dma_bus_setup_pSeriesLP: setting up bus %pOF\n",
+                dn);
+-      pdn = pci_dma_find(dn, &dma_window);
++      pdn = pci_dma_find(dn, &prop);
+-      if (dma_window == NULL)
+-              pr_debug("  no ibm,dma-window property !\n");
++      /* In PPC architecture, there will always be DMA window on bus or one of the
++       * parent bus. During reboot, there will be ibm,dma-window property to
++       * define DMA window. For kdump, there will at least be default window or DDW
++       * or both.
++       */
+       ppci = PCI_DN(pdn);
+@@ -766,13 +791,24 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)
+       if (!ppci->table_group) {
+               ppci->table_group = iommu_pseries_alloc_group(ppci->phb->node);
+               tbl = ppci->table_group->tables[0];
+-              if (dma_window) {
+-                      iommu_table_setparms_lpar(ppci->phb, pdn, tbl,
+-                                                ppci->table_group, dma_window);
+-                      if (!iommu_init_table(tbl, ppci->phb->node, 0, 0))
+-                              panic("Failed to initialize iommu table");
+-              }
++              iommu_table_setparms_common(tbl, ppci->phb->bus->number,
++                              be32_to_cpu(prop.liobn),
++                              be64_to_cpu(prop.dma_base),
++                              1ULL << be32_to_cpu(prop.window_shift),
++                              be32_to_cpu(prop.tce_shift), NULL,
++                              &iommu_table_lpar_multi_ops);
++
++              /* Only for normal boot with default window. Doesn't matter even
++               * if we set these with DDW which is 64bit during kdump, since
++               * these will not be used during kdump.
++               */
++              ppci->table_group->tce32_start = be64_to_cpu(prop.dma_base);
++              ppci->table_group->tce32_size = 1 << be32_to_cpu(prop.window_shift);
++
++              if (!iommu_init_table(tbl, ppci->phb->node, 0, 0))
++                      panic("Failed to initialize iommu table");
++
+               iommu_register_group(ppci->table_group,
+                               pci_domain_nr(bus), 0);
+               pr_debug("  created table: %p\n", ppci->table_group);
+@@ -960,6 +996,12 @@ static void find_existing_ddw_windows_named(const char *name)
+                       continue;
+               }
++              /* If at the time of system initialization, there are DDWs in OF,
++               * it means this is during kexec. DDW could be direct or dynamic.
++               * We will just mark DDWs as "dynamic" since this is kdump path,
++               * no need to worry about perforance. ddw_list_new_entry() will
++               * set window->direct = false.
++               */
+               window = ddw_list_new_entry(pdn, dma64);
+               if (!window) {
+                       of_node_put(pdn);
+@@ -1525,8 +1567,8 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
+ {
+       struct device_node *pdn, *dn;
+       struct iommu_table *tbl;
+-      const __be32 *dma_window = NULL;
+       struct pci_dn *pci;
++      struct dynamic_dma_window_prop prop;
+       pr_debug("pci_dma_dev_setup_pSeriesLP: %s\n", pci_name(dev));
+@@ -1539,7 +1581,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
+       dn = pci_device_to_OF_node(dev);
+       pr_debug("  node is %pOF\n", dn);
+-      pdn = pci_dma_find(dn, &dma_window);
++      pdn = pci_dma_find(dn, &prop);
+       if (!pdn || !PCI_DN(pdn)) {
+               printk(KERN_WARNING "pci_dma_dev_setup_pSeriesLP: "
+                      "no DMA window found for pci dev=%s dn=%pOF\n",
+@@ -1552,8 +1594,20 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev *dev)
+       if (!pci->table_group) {
+               pci->table_group = iommu_pseries_alloc_group(pci->phb->node);
+               tbl = pci->table_group->tables[0];
+-              iommu_table_setparms_lpar(pci->phb, pdn, tbl,
+-                              pci->table_group, dma_window);
++
++              iommu_table_setparms_common(tbl, pci->phb->bus->number,
++                              be32_to_cpu(prop.liobn),
++                              be64_to_cpu(prop.dma_base),
++                              1ULL << be32_to_cpu(prop.window_shift),
++                              be32_to_cpu(prop.tce_shift), NULL,
++                              &iommu_table_lpar_multi_ops);
++
++              /* Only for normal boot with default window. Doesn't matter even
++               * if we set these with DDW which is 64bit during kdump, since
++               * these will not be used during kdump.
++               */
++              pci->table_group->tce32_start = be64_to_cpu(prop.dma_base);
++              pci->table_group->tce32_size = 1 << be32_to_cpu(prop.window_shift);
+               iommu_init_table(tbl, pci->phb->node, 0, 0);
+               iommu_register_group(pci->table_group,
+-- 
+2.43.0
+
index 4de5b2fd6d3351035310ea75707fd74693a53c0e..20ffac0f4ad82778f8787aa75b847dec0e84c56a 100644 (file)
@@ -196,3 +196,9 @@ x86-boot-rename-conflicting-boot_params-pointer-to-boot_params_ptr.patch
 x86-boot-efistub-assign-global-boot_params-variable.patch
 efi-x86-fix-the-missing-kaslr_flag-bit-in-boot_params-hdr.loadflags.patch
 af_unix-drop-oob_skb-ref-before-purging-queue-in-gc.patch
+phy-freescale-phy-fsl-imx8-mipi-dphy-fix-alias-name-.patch
+powerpc-pseries-iommu-iommu-table-is-not-initialized.patch
+gpio-74x164-enable-output-pins-after-registers-are-r.patch
+gpiolib-fix-the-error-path-order-in-gpiochip_add_dat.patch
+gpio-fix-resource-unwinding-order-in-error-path.patch
+block-define-bvec_iter-as-__packed-__aligned-4.patch