Re: [PATCH] powerpc/iommu: DMA address offset is incorrectly calculated with 2MB TCEs
Gaurav Batra writes:
> When DMA window is backed by 2MB TCEs, the DMA address for the mapped
> page should be the offset of the page relative to the 2MB TCE. The code
> was incorrectly setting the DMA address to the beginning of the TCE
> range.
>
> Mellanox driver is reporting timeout trying to ENABLE_HCA for an SR-IOV
> ethernet port, when DMA window is backed by 2MB TCEs.
>
> Signed-off-by: Gaurav Batra
>
> Reviewed-by: Greg Joyce
> Reviewed-by: Brian King
> ---
> arch/powerpc/kernel/iommu.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
This should have a Fixes: tag.
I guess it's:
387273118714 ("powerps/pseries/dma: Add support for 2M IOMMU page size")
Can you confirm?
cheers
Re: [PATCH v3 02/14] arm64: drop ranges in definition of ARCH_FORCE_MAX_ORDER
On Wed, 12 Apr 2023 18:27:08 +0100 Catalin Marinas wrote: > > It sounds nice in theory. In practice. EXPERT hides too much. When you > > flip expert, you expose over a 175ish new config options which are > > hidden behind EXPERT. You don't have to know what you are doing just > > with the MAX_ORDER, but a whole bunch more as well. If everyone were > > already running 10, this might be less of a problem. At least Fedora > > and RHEL are running 13 for 4K pages on aarch64. This was not some > > accidental choice, we had to carry a patch to even allow it for a > > while. If this does go in as is, we will likely just carry a patch to > > remove the "if EXPERT", but that is a bit of a disservice to users who > > might be trying to debug something else upstream, bisecting upstream > > kernels or testing a patch. In those cases, people tend to use > > pristine upstream sources without distro patches to verify, and they > > tend to use their existing configs. With this change, their MAX_ORDER > > will drop to 10 from 13 silently. That can look like a different > > issue enough to ruin a bisect or have them give bad feedback on a > > patch because it introduces a "regression" which is not a regression > > at all, but a config change they couldn't see. > > If we remove EXPERT (as prior to this patch), I'd rather keep the ranges > and avoid having to explain to people why some random MAX_ORDER doesn't > build (keeping the range would also make sense for randconfig, not sure > we got to any conclusion there). Well this doesn't seem to have got anywhere. I think I'll send the patchset into Linus for the next merge window as-is. Please let's take a look at this Kconfig presentation issue during the following -rc cycle.
Re: [PATCH v2 0/2] start_kernel: omit stack canary
On Mon, Apr 17, 2023 at 03:00:04PM -0700, ndesaulni...@google.com wrote: > --- > Changes in v2: > - Rebase to avoid conflicts with Josh's changes. > - Fix comment style as per Peter. > - Pick up tags. > - Link to v1: > https://lore.kernel.org/r/20230412-no_stackp-v1-0-46a69b507...@google.com > (sorry for the spam with v2, mrincon is helping me get kinks worked out > with b4 and our corporate mailer) Acked-by: Josh Poimboeuf -- Josh
Re: [PATCH] PCI: Use of_property_present() for testing DT property presence
On Fri, Mar 10, 2023 at 08:47:19AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties. As
> part of this, convert of_get_property/of_find_property calls to the
> recently added of_property_present() helper when we just want to test
> for presence of a property and nothing more.
>
> Signed-off-by: Rob Herring
Applied with AngeloGioacchino's reviewed-by to pci/enumeration for
v6.4, thanks!
> ---
> drivers/pci/controller/pci-tegra.c | 4 ++--
> drivers/pci/controller/pcie-mediatek.c | 2 +-
> drivers/pci/hotplug/rpaphp_core.c | 4 ++--
> drivers/pci/of.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/controller/pci-tegra.c
> b/drivers/pci/controller/pci-tegra.c
> index 74c109f14ff0..79630885b9c8 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -1375,7 +1375,7 @@ static int tegra_pcie_phys_get(struct tegra_pcie *pcie)
> struct tegra_pcie_port *port;
> int err;
>
> - if (!soc->has_gen2 || of_find_property(np, "phys", NULL) != NULL)
> + if (!soc->has_gen2 || of_property_present(np, "phys"))
> return tegra_pcie_phys_get_legacy(pcie);
>
> list_for_each_entry(port, >ports, list) {
> @@ -1944,7 +1944,7 @@ static bool of_regulator_bulk_available(struct
> device_node *np,
> for (i = 0; i < num_supplies; i++) {
> snprintf(property, 32, "%s-supply", supplies[i].supply);
>
> - if (of_find_property(np, property, NULL) == NULL)
> + if (!of_property_present(np, property))
> return false;
> }
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c
> b/drivers/pci/controller/pcie-mediatek.c
> index ae5ad05ddc1d..31de7a29192c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -643,7 +643,7 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
> return err;
> }
>
> - if (of_find_property(dev->of_node, "interrupt-names", NULL))
> + if (of_property_present(dev->of_node, "interrupt-names"))
> port->irq = platform_get_irq_byname(pdev, "pcie_irq");
> else
> port->irq = platform_get_irq(pdev, port->slot);
> diff --git a/drivers/pci/hotplug/rpaphp_core.c
> b/drivers/pci/hotplug/rpaphp_core.c
> index 491986197c47..2316de0fd198 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -278,7 +278,7 @@ int rpaphp_check_drc_props(struct device_node *dn, char
> *drc_name,
> return -EINVAL;
> }
>
> - if (of_find_property(dn->parent, "ibm,drc-info", NULL))
> + if (of_property_present(dn->parent, "ibm,drc-info"))
> return rpaphp_check_drc_props_v2(dn, drc_name, drc_type,
> be32_to_cpu(*my_index));
> else
> @@ -440,7 +440,7 @@ int rpaphp_add_slot(struct device_node *dn)
> if (!of_node_name_eq(dn, "pci"))
> return 0;
>
> - if (of_find_property(dn, "ibm,drc-info", NULL))
> + if (of_property_present(dn, "ibm,drc-info"))
> return rpaphp_drc_info_add_slot(dn);
> else
> return rpaphp_drc_add_slot(dn);
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 196834ed44fe..e085f2eca372 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -447,7 +447,7 @@ static int of_irq_parse_pci(const struct pci_dev *pdev,
> struct of_phandle_args *
> return -ENODEV;
>
> /* Local interrupt-map in the device node? Use it! */
> - if (of_get_property(dn, "interrupt-map", NULL)) {
> + if (of_property_present(dn, "interrupt-map")) {
> pin = pci_swizzle_interrupt_pin(pdev, pin);
> ppnode = dn;
> }
> --
> 2.39.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v14 03/15] dt-bindings: Convert gpio-mmio to yaml
On Thu, Apr 13, 2023 at 12:05:55PM -0400, Sean Anderson wrote:
> This is a generic binding for simple MMIO GPIO controllers. Although we
> have a single driver for these controllers, they were previously spread
> over several files. Consolidate them. The register descriptions are
> adapted from the comments in the source. There is no set order for the
> registers, and some registers may be omitted. Because of this, reg-names
> is mandatory, and no order is specified.
>
> Rename brcm,bcm6345-gpio to brcm,bcm63xx-gpio to reflect that bcm6345
> has moved.
>
> Signed-off-by: Sean Anderson
> Reviewed-by: Linus Walleij
> ---
> Linus or Bartosz, feel free to pick this up as the rest of this series
> may not be merged any time soon.
>
> Changes in v14:
> - Fix incorrect $id
>
> Changes in v13:
> - Fix references to brcm,bcm63xx-gpio.yaml (neé brcm,bcm6345-gpio)
>
> Changes in v12:
> - Put compatible first
> - Keep gpio-controller to one line
> - Add little-endian property
> - Alphabetize compatibles
> - Remove some comments
> - Remove some examples with insufficient novelty
>
> Changes in v11:
> - Keep empty (or almost-empty) properties on a single line
> - Don't use | unnecessarily
> - Use gpio as the node name for examples
> - Rename brcm,bcm6345-gpio.yaml to brcm,bcm63xx-gpio.yaml
>
> Changes in v10:
> - New
>
> ...m6345-gpio.yaml => brcm,bcm63xx-gpio.yaml} | 18 +--
> .../devicetree/bindings/gpio/gpio-mmio.yaml | 117 ++
> .../bindings/gpio/ni,169445-nand-gpio.txt | 38 --
> .../devicetree/bindings/gpio/wd,mbl-gpio.txt | 38 --
> .../mfd/brcm,bcm6318-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm63268-gpio-sysctl.yaml| 4 +-
> .../mfd/brcm,bcm6328-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6358-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6362-gpio-sysctl.yaml | 4 +-
> .../mfd/brcm,bcm6368-gpio-sysctl.yaml | 4 +-
> 10 files changed, 131 insertions(+), 104 deletions(-)
> rename Documentation/devicetree/bindings/gpio/{brcm,bcm6345-gpio.yaml =>
> brcm,bcm63xx-gpio.yaml} (75%)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> delete mode 100644
> Documentation/devicetree/bindings/gpio/ni,169445-nand-gpio.txt
> delete mode 100644 Documentation/devicetree/bindings/gpio/wd,mbl-gpio.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
> similarity index 75%
> rename from Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> rename to Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
> index 4d69f79df859..62fcc2bd5d80 100644
> --- a/Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.yaml
> +++ b/Documentation/devicetree/bindings/gpio/brcm,bcm63xx-gpio.yaml
> @@ -1,10 +1,10 @@
> # SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> %YAML 1.2
> ---
> -$id: http://devicetree.org/schemas/gpio/brcm,bcm6345-gpio.yaml#
> +$id: http://devicetree.org/schemas/gpio/brcm,bcm63xx-gpio.yaml#
> $schema: http://devicetree.org/meta-schemas/core.yaml#
>
> -title: Broadcom BCM6345 GPIO controller
> +title: Broadcom BCM63xx GPIO controller
>
> maintainers:
>- Álvaro Fernández Rojas
> @@ -18,8 +18,6 @@ description: |+
>
>BCM6338 have 8-bit data and dirout registers, where GPIO state can be read
>and/or written, and the direction changed from input to output.
> - BCM6345 have 16-bit data and dirout registers, where GPIO state can be read
> - and/or written, and the direction changed from input to output.
>BCM6318, BCM6328, BCM6358, BCM6362, BCM6368 and BCM63268 have 32-bit data
>and dirout registers, where GPIO state can be read and/or written, and the
>direction changed from input to output.
> @@ -29,7 +27,6 @@ properties:
> enum:
>- brcm,bcm6318-gpio
>- brcm,bcm6328-gpio
> - - brcm,bcm6345-gpio
>- brcm,bcm6358-gpio
>- brcm,bcm6362-gpio
>- brcm,bcm6368-gpio
> @@ -63,17 +60,6 @@ required:
> additionalProperties: false
>
> examples:
> - - |
> -gpio@fffe0406 {
> - compatible = "brcm,bcm6345-gpio";
> - reg-names = "dirout", "dat";
> - reg = <0xfffe0406 2>, <0xfffe040a 2>;
> - native-endian;
> -
> - gpio-controller;
> - #gpio-cells = <2>;
> -};
> -
>- |
> gpio@0 {
>compatible = "brcm,bcm63268-gpio";
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> new file mode 100644
> index ..b394e058256e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> @@ -0,0 +1,117 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/gpio-mmio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Generic MMIO GPIO
> +
> +maintainers:
> + - Linus
Re: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
Hi Stefan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 6a8f57ae2eb07ab39a6f0ccad60c760743051026]
url:
https://github.com/intel-lab-lkp/linux/commits/Stefan-Berger/drivers-of-kexec-ima-Support-32-bit-platforms/20230418-214600
base: 6a8f57ae2eb07ab39a6f0ccad60c760743051026
patch link:
https://lore.kernel.org/r/20230418134409.177485-5-stefanb%40linux.ibm.com
patch subject: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in
of-tree for kexec
config: x86_64-randconfig-a013-20230417
(https://download.01.org/0day-ci/archive/20230419/202304190215.d0zwo1ni-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/16a833d47b9aca53a1b099dea4066b76b7f14ee1
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Stefan-Berger/drivers-of-kexec-ima-Support-32-bit-platforms/20230418-214600
git checkout 16a833d47b9aca53a1b099dea4066b76b7f14ee1
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1
O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/mailbox/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304190215.d0zwo1ni-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from drivers/mailbox/mailbox.c:18:
In file included from include/linux/mailbox_client.h:10:
>> include/linux/of.h:1664:48: warning: declaration of 'struct kimage' will not
>> be visible outside of this function [-Wvisibility]
static inline void tpm_add_kexec_buffer(struct kimage *image) { }
^
1 warning generated.
vim +1664 include/linux/of.h
1660
1661 #if defined(CONFIG_KEXEC_FILE) && defined(CONFIG_OF_FLATTREE)
1662 void tpm_add_kexec_buffer(struct kimage *image);
1663 #else
> 1664 static inline void tpm_add_kexec_buffer(struct kimage *image) { }
1665 #endif
1666
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Tue, Apr 18, 2023 at 07:25:00PM +0100, Mark Brown wrote:
> On Tue, Apr 18, 2023 at 11:21:45AM -0700, Nathan Chancellor wrote:
> > On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote:
>
> > > Done.
>
> > Thanks a lot, sorry for not saying it sooner! It looks like this
> > regressed in next-20230417 and next-20230418 though.
>
> Someone sent a mail saying they thought they'd fixed the DRM tree - is
> that not the case?
Does not seem like it:
$ git show -s --format='%h ("%s")'
67d5d9f013d6 ("Add linux-next specific files for 20230418")
$ git grep DRM_AMD_DC_DCN
drivers/gpu/drm/amd/display/Kconfig:select DRM_AMD_DC_DCN if (X86 || (PPC64
&& ALTIVEC) || (ARM64 && KERNEL_MODE_NEON && !CC_IS_CLANG))
Cheers,
Nathan
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Tue, Apr 18, 2023 at 11:21:45AM -0700, Nathan Chancellor wrote: > On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote: > > Done. > Thanks a lot, sorry for not saying it sooner! It looks like this > regressed in next-20230417 and next-20230418 though. Someone sent a mail saying they thought they'd fixed the DRM tree - is that not the case? signature.asc Description: PGP signature
Re: linux-next: manual merge of the drm tree with the powerpc tree
On Fri, Apr 14, 2023 at 05:55:10PM +0100, Mark Brown wrote: > On Thu, Apr 13, 2023 at 11:47:25AM -0700, Nathan Chancellor wrote: > > On Wed, Apr 12, 2023 at 11:22:13AM +1000, Stephen Rothwell wrote: > > > select SND_HDA_COMPONENT if SND_HDA_CORE > > # !CC_IS_CLANG: https://github.com/ClangBuiltLinux/linux/issues/1752 > > - select DRM_AMD_DC_DCN if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > > KERNEL_MODE_NEON && !CC_IS_CLANG)) > > + select DRM_AMD_DC_FP if (X86 || (PPC64 && ALTIVEC) || (ARM64 && > > KERNEL_MODE_NEON && !CC_IS_CLANG)) > > help > > Choose this option if you want to use the new display engine > > support for AMDGPU. This adds required support for Vega and > > > Please consider resolving this in a future -next update, I was rather > > surprised that my AMD test machine's graphical output was not working > > until I noticed the configuration difference :) > > Done. Thanks a lot, sorry for not saying it sooner! It looks like this regressed in next-20230417 and next-20230418 though. Cheers, Nathan
Re: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
Hi Stefan,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 6a8f57ae2eb07ab39a6f0ccad60c760743051026]
url:
https://github.com/intel-lab-lkp/linux/commits/Stefan-Berger/drivers-of-kexec-ima-Support-32-bit-platforms/20230418-214600
base: 6a8f57ae2eb07ab39a6f0ccad60c760743051026
patch link:
https://lore.kernel.org/r/20230418134409.177485-5-stefanb%40linux.ibm.com
patch subject: [PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in
of-tree for kexec
config: um-i386_defconfig
(https://download.01.org/0day-ci/archive/20230419/202304190146.frlhobob-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/16a833d47b9aca53a1b099dea4066b76b7f14ee1
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Stefan-Berger/drivers-of-kexec-ima-Support-32-bit-platforms/20230418-214600
git checkout 16a833d47b9aca53a1b099dea4066b76b7f14ee1
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=um SUBARCH=i386 olddefconfig
make W=1 O=build_dir ARCH=um SUBARCH=i386 SHELL=/bin/bash
drivers/input/mouse/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
| Link:
https://lore.kernel.org/oe-kbuild-all/202304190146.frlhobob-...@intel.com/
All warnings (new ones prefixed by >>):
In file included from include/linux/irqdomain.h:36,
from include/linux/acpi.h:13,
from include/linux/i2c.h:13,
from drivers/input/mouse/synaptics.c:30:
>> include/linux/of.h:1664:48: warning: 'struct kimage' declared inside
>> parameter list will not be visible outside of this definition or declaration
1664 | static inline void tpm_add_kexec_buffer(struct kimage *image) { }
|^~
drivers/input/mouse/synaptics.c:164:27: warning: 'smbus_pnp_ids' defined but
not used [-Wunused-const-variable=]
164 | static const char * const smbus_pnp_ids[] = {
| ^
vim +1664 include/linux/of.h
1660
1661 #if defined(CONFIG_KEXEC_FILE) && defined(CONFIG_OF_FLATTREE)
1662 void tpm_add_kexec_buffer(struct kimage *image);
1663 #else
> 1664 static inline void tpm_add_kexec_buffer(struct kimage *image) { }
1665 #endif
1666
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
* Laurent Dufour [2023-04-13 17:38:51]: > On 13/04/2023 15:37:59, Michael Ellerman wrote: > > Hi Laurent, > > > > Laurent Dufour writes: > >> There is no SMT level recorded in the kernel neither in user space. > >> Indeed there is no real constraint about that and mixed SMT levels are > >> allowed and system is working fine this way. > >> > >> However when new CPU are added, the kernel is onlining all the threads > >> which is leading to mixed SMT levels and confuse end user a bit. > >> > >> To prevent this exports a SMT level from the kernel so user space > >> application like the energy daemon, could read it to adjust their settings. > >> There is no action unless recording the value when a SMT value is written > >> into the new sysfs entry. User space applications like ppc64_cpu should > >> update the sysfs when changing the SMT level to keep the system consistent. > >> > >> Suggested-by: Srikar Dronamraju > >> Signed-off-by: Laurent Dufour > >> --- > >> arch/powerpc/platforms/pseries/pseries.h | 3 ++ > >> arch/powerpc/platforms/pseries/smp.c | 39 > >> 2 files changed, 42 insertions(+) > > > > There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt > > > > I think we should be enabling that on powerpc and then adapting it to > > our needs, rather than adding a pseries specific file. > > Thanks Michael, I was not aware of this sysfs interface. > > > Currently the generic code is only aware of SMT on/off, so it would need > > to be taught about SMT4 and 8 at least. > > Do you think we should limit our support to SMT4 and SMT8 only? smt2 is also a valid already supported configuration and we are evaluating smt6 mode based on some inputs from ISV teams. So I believe having a value for all modes would be good. > > > There are already hooks in the generic code to check the SMT level when > > bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries > > hotplug case too, though maybe we need some additional logic. > > > > Wiring up the basic support is pretty straight forward, something like > > the diff below. > -- Thanks and Regards Srikar Dronamraju
Re: [PATCH] PCI: Use of_property_present() for testing DT property presence
On Fri, Mar 10, 2023 at 08:47:19AM -0600, Rob Herring wrote:
> It is preferred to use typed property access functions (i.e.
> of_property_read_ functions) rather than low-level
> of_get_property/of_find_property functions for reading properties. As
> part of this, convert of_get_property/of_find_property calls to the
> recently added of_property_present() helper when we just want to test
> for presence of a property and nothing more.
>
> Signed-off-by: Rob Herring
> ---
> drivers/pci/controller/pci-tegra.c | 4 ++--
> drivers/pci/controller/pcie-mediatek.c | 2 +-
> drivers/pci/hotplug/rpaphp_core.c | 4 ++--
> drivers/pci/of.c | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
Ping!
>
> diff --git a/drivers/pci/controller/pci-tegra.c
> b/drivers/pci/controller/pci-tegra.c
> index 74c109f14ff0..79630885b9c8 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -1375,7 +1375,7 @@ static int tegra_pcie_phys_get(struct tegra_pcie *pcie)
> struct tegra_pcie_port *port;
> int err;
>
> - if (!soc->has_gen2 || of_find_property(np, "phys", NULL) != NULL)
> + if (!soc->has_gen2 || of_property_present(np, "phys"))
> return tegra_pcie_phys_get_legacy(pcie);
>
> list_for_each_entry(port, >ports, list) {
> @@ -1944,7 +1944,7 @@ static bool of_regulator_bulk_available(struct
> device_node *np,
> for (i = 0; i < num_supplies; i++) {
> snprintf(property, 32, "%s-supply", supplies[i].supply);
>
> - if (of_find_property(np, property, NULL) == NULL)
> + if (!of_property_present(np, property))
> return false;
> }
>
> diff --git a/drivers/pci/controller/pcie-mediatek.c
> b/drivers/pci/controller/pcie-mediatek.c
> index ae5ad05ddc1d..31de7a29192c 100644
> --- a/drivers/pci/controller/pcie-mediatek.c
> +++ b/drivers/pci/controller/pcie-mediatek.c
> @@ -643,7 +643,7 @@ static int mtk_pcie_setup_irq(struct mtk_pcie_port *port,
> return err;
> }
>
> - if (of_find_property(dev->of_node, "interrupt-names", NULL))
> + if (of_property_present(dev->of_node, "interrupt-names"))
> port->irq = platform_get_irq_byname(pdev, "pcie_irq");
> else
> port->irq = platform_get_irq(pdev, port->slot);
> diff --git a/drivers/pci/hotplug/rpaphp_core.c
> b/drivers/pci/hotplug/rpaphp_core.c
> index 491986197c47..2316de0fd198 100644
> --- a/drivers/pci/hotplug/rpaphp_core.c
> +++ b/drivers/pci/hotplug/rpaphp_core.c
> @@ -278,7 +278,7 @@ int rpaphp_check_drc_props(struct device_node *dn, char
> *drc_name,
> return -EINVAL;
> }
>
> - if (of_find_property(dn->parent, "ibm,drc-info", NULL))
> + if (of_property_present(dn->parent, "ibm,drc-info"))
> return rpaphp_check_drc_props_v2(dn, drc_name, drc_type,
> be32_to_cpu(*my_index));
> else
> @@ -440,7 +440,7 @@ int rpaphp_add_slot(struct device_node *dn)
> if (!of_node_name_eq(dn, "pci"))
> return 0;
>
> - if (of_find_property(dn, "ibm,drc-info", NULL))
> + if (of_property_present(dn, "ibm,drc-info"))
> return rpaphp_drc_info_add_slot(dn);
> else
> return rpaphp_drc_add_slot(dn);
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 196834ed44fe..e085f2eca372 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -447,7 +447,7 @@ static int of_irq_parse_pci(const struct pci_dev *pdev,
> struct of_phandle_args *
> return -ENODEV;
>
> /* Local interrupt-map in the device node? Use it! */
> - if (of_get_property(dn, "interrupt-map", NULL)) {
> + if (of_property_present(dn, "interrupt-map")) {
> pin = pci_swizzle_interrupt_pin(pdev, pin);
> ppnode = dn;
> }
> --
> 2.39.2
>
[PATCH v4 5/6] mm/gup: remove vmas parameter from pin_user_pages()
We are now in a position where no caller of pin_user_pages() requires the
vmas parameter at all, so eliminate this parameter from the function and
all callers.
This clears the way to removing the vmas parameter from GUP altogether.
Acked-by: David Hildenbrand
Acked-by: Dennis Dalessandro (for qib)
Signed-off-by: Lorenzo Stoakes
---
arch/powerpc/mm/book3s64/iommu_api.c | 2 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 2 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 2 +-
drivers/infiniband/sw/siw/siw_mem.c| 2 +-
drivers/media/v4l2-core/videobuf-dma-sg.c | 2 +-
drivers/vdpa/vdpa_user/vduse_dev.c | 2 +-
drivers/vhost/vdpa.c | 2 +-
include/linux/mm.h | 3 +--
io_uring/rsrc.c| 4 +---
mm/gup.c | 9 +++--
mm/gup_test.c | 9 -
net/xdp/xdp_umem.c | 2 +-
12 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
b/arch/powerpc/mm/book3s64/iommu_api.c
index 81d7185e2ae8..d19fb1f3007d 100644
--- a/arch/powerpc/mm/book3s64/iommu_api.c
+++ b/arch/powerpc/mm/book3s64/iommu_api.c
@@ -105,7 +105,7 @@ static long mm_iommu_do_alloc(struct mm_struct *mm,
unsigned long ua,
ret = pin_user_pages(ua + (entry << PAGE_SHIFT), n,
FOLL_WRITE | FOLL_LONGTERM,
- mem->hpages + entry, NULL);
+ mem->hpages + entry);
if (ret == n) {
pinned += n;
continue;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index f693bc753b6b..1bb7507325bc 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -111,7 +111,7 @@ int qib_get_user_pages(unsigned long start_page, size_t
num_pages,
ret = pin_user_pages(start_page + got * PAGE_SIZE,
num_pages - got,
FOLL_LONGTERM | FOLL_WRITE,
-p + got, NULL);
+p + got);
if (ret < 0) {
mmap_read_unlock(current->mm);
goto bail_release;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 2a5cac2658ec..84e0f41e7dfa 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -140,7 +140,7 @@ static int usnic_uiom_get_pages(unsigned long addr, size_t
size, int writable,
ret = pin_user_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof(struct page *)),
-gup_flags, page_list, NULL);
+gup_flags, page_list);
if (ret < 0)
goto out;
diff --git a/drivers/infiniband/sw/siw/siw_mem.c
b/drivers/infiniband/sw/siw/siw_mem.c
index f51ab2ccf151..e6e25f15567d 100644
--- a/drivers/infiniband/sw/siw/siw_mem.c
+++ b/drivers/infiniband/sw/siw/siw_mem.c
@@ -422,7 +422,7 @@ struct siw_umem *siw_umem_get(u64 start, u64 len, bool
writable)
umem->page_chunk[i].plist = plist;
while (nents) {
rv = pin_user_pages(first_page_va, nents, foll_flags,
- plist, NULL);
+ plist);
if (rv < 0)
goto out_sem_up;
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 53001532e8e3..405b89ea1054 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -180,7 +180,7 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
data, size, dma->nr_pages);
err = pin_user_pages(data & PAGE_MASK, dma->nr_pages, gup_flags,
-dma->pages, NULL);
+dma->pages);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c
b/drivers/vdpa/vdpa_user/vduse_dev.c
index 0c3b48616a9f..1f80254604f0 100644
--- a/drivers/vdpa/vdpa_user/vduse_dev.c
+++ b/drivers/vdpa/vdpa_user/vduse_dev.c
@@ -995,7 +995,7 @@ static int vduse_dev_reg_umem(struct vduse_dev *dev,
goto out;
pinned = pin_user_pages(uaddr, npages, FOLL_LONGTERM | FOLL_WRITE,
- page_list, NULL);
+ page_list);
if (pinned != npages) {
ret = pinned < 0 ? pinned : -ENOMEM;
goto
Re: [PATCH 01/33] s390: Use _pt_s390_gaddr for gmap address tracking
On 17.04.23 22:50, Vishal Moola (Oracle) wrote:
s390 uses page->index to keep track of page tables for the guest address
space. In an attempt to consolidate the usage of page fields in s390,
replace _pt_pad_2 with _pt_s390_gaddr to replace page->index in gmap.
This will help with the splitting of struct ptdesc from struct page, as
well as allow s390 to use _pt_frag_refcount for fragmented page table
tracking.
Since page->_pt_s390_gaddr aliases with mapping, ensure its set to NULL
before freeing the pages as well.
Signed-off-by: Vishal Moola (Oracle)
---
[...]
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 3fc9e680f174..2616d64c0e8c 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -144,7 +144,7 @@ struct page {
struct {/* Page table pages */
unsigned long _pt_pad_1;/* compound_head */
pgtable_t pmd_huge_pte; /* protected by page->ptl */
- unsigned long _pt_pad_2;/* mapping */
+ unsigned long _pt_s390_gaddr; /* mapping */
union {
struct mm_struct *pt_mm; /* x86 pgds only */
atomic_t pt_frag_refcount; /* powerpc */
The confusing part is, that these gmap page tables are not ordinary
process page tables that we would ordinarily place into this section
here. That's why they are also not allocated/freed using the typical
page table constructor/destructor ...
--
Thanks,
David / dhildenb
Re: [PATCH v3 2/2] soc: fsl: qbman: Use raw spinlock for cgr_lock
On 4/18/23 02:29, Crystal Wood wrote:
> On Tue, 2023-04-11 at 11:09 -0400, Sean Anderson wrote:
>> Hi Crystal,
>>
>> On 4/4/23 12:04, Sean Anderson wrote:
>> > On 4/4/23 11:33, Crystal Wood wrote:
>> > > On Tue, 2023-04-04 at 10:55 -0400, Sean Anderson wrote:
>> > >
>> > > > @@ -1456,11 +1456,11 @@ static void tqm_congestion_task(struct
>> > > > work_struct
>> > > > *work)
>> > > > union qm_mc_result *mcr;
>> > > > struct qman_cgr *cgr;
>> > > >
>> > > > - spin_lock_irq(>cgr_lock);
>> > > > + raw_spin_lock_irq(>cgr_lock);
>> > > > qm_mc_start(>p);
>> > > > qm_mc_commit(>p, QM_MCC_VERB_QUERYCONGESTION);
>> > > > if (!qm_mc_result_timeout(>p, )) {
>> > > > - spin_unlock_irq(>cgr_lock);
>> > > > + raw_spin_unlock_irq(>cgr_lock);
>> > >
>> > > qm_mc_result_timeout() spins with a timeout of 10 ms which is very
>> > > inappropriate for a raw lock. What is the actual expected upper bound?
>> >
>> > Hm, maybe we can move this qm_mc stuff outside cgr_lock? In most other
>> > places they're called without cgr_lock, which implies that its usage
>> > here is meant to synchronize against some other function.
>>
>> Do you have any suggestions here? I think this should really be handled
>> in a follow-up patch. If you think this code is waiting too long in a raw
>> spinlock, the existing code can wait just as long with IRQs disabled.
>> This patch doesn't change existing system responsiveness.
>
> Well, AFAICT it expands the situations in which it happens from configuration
> codepaths to stuff like congestion handling. The proper fix would probably be
> to use some mechanism other than smp_call_function_single() to run code on the
> target cpu so that it can run with irqs enabled (or get confirmation that the
> actual worst case is short enough),
Well, we used to use a kthread/wait_for_completion before 96f413f47677
("soc/fsl/qbman: fix issue in qman_delete_cgr_safe()"). The commit
description there isn't very enlightening as to the actual bug, which is
why I CC's Madalin earlier. To be honest, I'm not really familiar with
the other options in the kernel.
> but barring that I guess at least acknowledge the situation in a
> comment?
Fine by me.
--Sean
[PATCH v9 3/4] of: kexec: Refactor IMA buffer related functions to make them reusable
Refactor IMA buffer related functions to make them reusable for carrying
TPM logs across kexec.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Mimi Zohar
Reviewed-by: Mimi Zohar
Reviewed-by: Rob Herring
Tested-by: Nageswara R Sastry
Tested-by: Coiby Xu
---
v6:
- Add __init to get_kexec_buffer as suggested by Jonathan
v5:
- Rebased on Jonathan McDowell's commit "b69a2afd5afc x86/kexec: Carry
forward IMA measurement log on kexec"
v4:
- Move debug output into setup_buffer()
---
drivers/of/kexec.c | 126 ++---
1 file changed, 74 insertions(+), 52 deletions(-)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 1373d7e0a9b3..fa8c0c75adf9 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -117,45 +117,57 @@ static int do_get_kexec_buffer(const void *prop, int len,
unsigned long *addr,
}
#ifdef CONFIG_HAVE_IMA_KEXEC
-/**
- * ima_get_kexec_buffer - get IMA buffer from the previous kernel
- * @addr: On successful return, set to point to the buffer contents.
- * @size: On successful return, set to the buffer size.
- *
- * Return: 0 on success, negative errno on error.
- */
-int __init ima_get_kexec_buffer(void **addr, size_t *size)
+static int __init get_kexec_buffer(const char *name, unsigned long *addr,
+ size_t *size)
{
int ret, len;
- unsigned long tmp_addr;
unsigned long start_pfn, end_pfn;
- size_t tmp_size;
const void *prop;
- prop = of_get_property(of_chosen, "linux,ima-kexec-buffer", );
+ prop = of_get_property(of_chosen, name, );
if (!prop)
return -ENOENT;
- ret = do_get_kexec_buffer(prop, len, _addr, _size);
+ ret = do_get_kexec_buffer(prop, len, addr, size);
if (ret)
return ret;
- /* Do some sanity on the returned size for the ima-kexec buffer */
- if (!tmp_size)
+ /* Do some sanity on the returned size for the kexec buffer */
+ if (!*size)
return -ENOENT;
/*
* Calculate the PFNs for the buffer and ensure
* they are with in addressable memory.
*/
- start_pfn = PHYS_PFN(tmp_addr);
- end_pfn = PHYS_PFN(tmp_addr + tmp_size - 1);
+ start_pfn = PHYS_PFN(*addr);
+ end_pfn = PHYS_PFN(*addr + *size - 1);
if (!page_is_ram(start_pfn) || !page_is_ram(end_pfn)) {
- pr_warn("IMA buffer at 0x%lx, size = 0x%zx beyond memory\n",
- tmp_addr, tmp_size);
+ pr_warn("%s buffer at 0x%lx, size = 0x%zx beyond memory\n",
+ name, *addr, *size);
return -EINVAL;
}
+ return 0;
+}
+
+/**
+ * ima_get_kexec_buffer - get IMA buffer from the previous kernel
+ * @addr: On successful return, set to point to the buffer contents.
+ * @size: On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+int __init ima_get_kexec_buffer(void **addr, size_t *size)
+{
+ int ret;
+ unsigned long tmp_addr;
+ size_t tmp_size;
+
+ ret = get_kexec_buffer("linux,ima-kexec-buffer", _addr, _size);
+ if (ret)
+ return ret;
+
*addr = __va(tmp_addr);
*size = tmp_size;
@@ -188,72 +200,82 @@ int __init ima_free_kexec_buffer(void)
}
#endif
-/**
- * remove_ima_buffer - remove the IMA buffer property and reservation from @fdt
- *
- * @fdt: Flattened Device Tree to update
- * @chosen_node: Offset to the chosen node in the device tree
- *
- * The IMA measurement buffer is of no use to a subsequent kernel, so we always
- * remove it from the device tree.
- */
-static void remove_ima_buffer(void *fdt, int chosen_node)
+static int remove_buffer(void *fdt, int chosen_node, const char *name)
{
int ret, len;
unsigned long addr;
size_t size;
const void *prop;
- if (!IS_ENABLED(CONFIG_HAVE_IMA_KEXEC))
- return;
-
- prop = fdt_getprop(fdt, chosen_node, "linux,ima-kexec-buffer", );
+ prop = fdt_getprop(fdt, chosen_node, name, );
if (!prop)
- return;
+ return -ENOENT;
ret = do_get_kexec_buffer(prop, len, , );
- fdt_delprop(fdt, chosen_node, "linux,ima-kexec-buffer");
+ fdt_delprop(fdt, chosen_node, name);
if (ret)
- return;
+ return ret;
ret = fdt_find_and_del_mem_rsv(fdt, addr, size);
if (!ret)
- pr_debug("Removed old IMA buffer reservation.\n");
+ pr_debug("Remove old %s buffer reserveration", name);
+ return ret;
}
-#ifdef CONFIG_IMA_KEXEC
/**
- * setup_ima_buffer - add IMA buffer information to the fdt
- * @image: kexec image being loaded.
- * @fdt: Flattened device tree for the next kernel.
- * @chosen_node: Offset to the chosen node.
+ *
[PATCH v9 2/4] tpm: of: Make of-tree specific function commonly available
Simplify tpm_read_log_of() by moving reusable parts of the code into
an inline function that makes it commonly available so it can be
used also for kexec support. Call the new of_tpm_get_sml_parameters()
function from the TPM Open Firmware driver.
Signed-off-by: Stefan Berger
Cc: Jarkko Sakkinen
Cc: Jason Gunthorpe
Cc: Rob Herring
Cc: Frank Rowand
Reviewed-by: Mimi Zohar
Tested-by: Nageswara R Sastry
Tested-by: Coiby Xu
Acked-by: Jarkko Sakkinen
---
v9:
- Rebased on 6.3-rc7; call tpm_read_log_memory_region if -ENODEV returned
v7:
- Added original comment back into inlined function
v4:
- converted to inline function
---
drivers/char/tpm/eventlog/of.c | 30 +---
include/linux/tpm.h| 36 ++
2 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/drivers/char/tpm/eventlog/of.c b/drivers/char/tpm/eventlog/of.c
index 930fe43d5daf..41688d9cbd3b 100644
--- a/drivers/char/tpm/eventlog/of.c
+++ b/drivers/char/tpm/eventlog/of.c
@@ -51,11 +51,10 @@ static int tpm_read_log_memory_region(struct tpm_chip *chip)
int tpm_read_log_of(struct tpm_chip *chip)
{
struct device_node *np;
- const u32 *sizep;
- const u64 *basep;
struct tpm_bios_log *log;
u32 size;
u64 base;
+ int ret;
log = >log;
if (chip->dev.parent && chip->dev.parent->of_node)
@@ -66,30 +65,11 @@ int tpm_read_log_of(struct tpm_chip *chip)
if (of_property_read_bool(np, "powered-while-suspended"))
chip->flags |= TPM_CHIP_FLAG_ALWAYS_POWERED;
- sizep = of_get_property(np, "linux,sml-size", NULL);
- basep = of_get_property(np, "linux,sml-base", NULL);
- if (sizep == NULL && basep == NULL)
+ ret = of_tpm_get_sml_parameters(np, , );
+ if (ret == -ENODEV)
return tpm_read_log_memory_region(chip);
- if (sizep == NULL || basep == NULL)
- return -EIO;
-
- /*
-* For both vtpm/tpm, firmware has log addr and log size in big
-* endian format. But in case of vtpm, there is a method called
-* sml-handover which is run during kernel init even before
-* device tree is setup. This sml-handover function takes care
-* of endianness and writes to sml-base and sml-size in little
-* endian format. For this reason, vtpm doesn't need conversion
-* but physical tpm needs the conversion.
-*/
- if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
- of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
- size = be32_to_cpup((__force __be32 *)sizep);
- base = be64_to_cpup((__force __be64 *)basep);
- } else {
- size = *sizep;
- base = *basep;
- }
+ if (ret < 0)
+ return ret;
if (size == 0) {
dev_warn(>dev, "%s: Event log area empty\n", __func__);
diff --git a/include/linux/tpm.h b/include/linux/tpm.h
index 4dc97b9f65fb..dd9a376a1dbb 100644
--- a/include/linux/tpm.h
+++ b/include/linux/tpm.h
@@ -461,4 +461,40 @@ static inline struct tpm_chip *tpm_default_chip(void)
return NULL;
}
#endif
+
+#ifdef CONFIG_OF
+static inline int of_tpm_get_sml_parameters(struct device_node *np,
+ u64 *base, u32 *size)
+{
+ const u32 *sizep;
+ const u64 *basep;
+
+ sizep = of_get_property(np, "linux,sml-size", NULL);
+ basep = of_get_property(np, "linux,sml-base", NULL);
+ if (sizep == NULL && basep == NULL)
+ return -ENODEV;
+ if (sizep == NULL || basep == NULL)
+ return -EIO;
+
+ /*
+* For both vtpm/tpm, firmware has log addr and log size in big
+* endian format. But in case of vtpm, there is a method called
+* sml-handover which is run during kernel init even before
+* device tree is setup. This sml-handover function takes care
+* of endianness and writes to sml-base and sml-size in little
+* endian format. For this reason, vtpm doesn't need conversion
+* but physical tpm needs the conversion.
+*/
+ if (of_property_match_string(np, "compatible", "IBM,vtpm") < 0 &&
+ of_property_match_string(np, "compatible", "IBM,vtpm20") < 0) {
+ *size = be32_to_cpup((__force __be32 *)sizep);
+ *base = be64_to_cpup((__force __be64 *)basep);
+ } else {
+ *size = *sizep;
+ *base = *basep;
+ }
+ return 0;
+}
+#endif
+
#endif
--
2.38.1
[PATCH v9 1/4] drivers: of: kexec ima: Support 32-bit platforms
From: Palmer Dabbelt
RISC-V recently added kexec_file() support, which uses enables kexec
IMA. We're the first 32-bit platform to support this, so we found a
build bug.
Acked-by: Rob Herring
Signed-off-by: Palmer Dabbelt
Reviewed-by: Mimi Zohar
---
drivers/of/kexec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index f26d2ba8a371..1373d7e0a9b3 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -250,8 +250,8 @@ static int setup_ima_buffer(const struct kimage *image,
void *fdt,
if (ret)
return -EINVAL;
- pr_debug("IMA buffer at 0x%llx, size = 0x%zx\n",
-image->ima_buffer_addr, image->ima_buffer_size);
+ pr_debug("IMA buffer at 0x%pa, size = 0x%zx\n",
+>ima_buffer_addr, image->ima_buffer_size);
return 0;
}
--
2.38.1
[PATCH v9 4/4] tpm/kexec: Duplicate TPM measurement log in of-tree for kexec
The memory area of the TPM measurement log is currently not properly
duplicated for carrying it across kexec when an Open Firmware
Devicetree is used. Therefore, the contents of the log get corrupted.
Fix this for the kexec_file_load() syscall by allocating a buffer and
copying the contents of the existing log into it. The new buffer is
preserved across the kexec and a pointer to it is available when the new
kernel is started. To achieve this, store the allocated buffer's address
in the flattened device tree (fdt) under the name linux,tpm-kexec-buffer
and search for this entry early in the kernel startup before the TPM
subsystem starts up. Adjust the pointer in the of-tree stored under
linux,sml-base to point to this buffer holding the preserved log. The TPM
driver can then read the base address from this entry when making the log
available. Invalidate the log by removing 'linux,sml-base' from the
devicetree if anything goes wrong with updating the buffer.
Use subsys_initcall() to call the function to restore the buffer even if
the TPM subsystem or driver are not used. This allows the buffer to be
carried across the next kexec without involvement of the TPM subsystem
and ensures a valid buffer pointed to by the of-tree.
Use the subsys_initcall(), rather than an ealier initcall, since
page_is_ram() in get_kexec_buffer() only starts working at this stage.
Signed-off-by: Stefan Berger
Cc: Rob Herring
Cc: Frank Rowand
Cc: Eric Biederman
Tested-by: Nageswara R Sastry
Tested-by: Coiby Xu
Reviewed-by: Rob Herring
---
v6:
- Define prototype for tpm_add_kexec_buffer under same config options
as drivers/of/kexec.c is compiled, provide inline function otherwise.
(kernel test robot)
v4:
- Added #include due to parisc
- Use phys_addr_t for physical address rather than void *
- Remove linux,sml-base if the buffer cannot be updated after a kexec
- Added __init to functions where possible
---
drivers/of/kexec.c| 216 +-
include/linux/kexec.h | 6 ++
include/linux/of.h| 6 ++
kernel/kexec_file.c | 6 ++
4 files changed, 232 insertions(+), 2 deletions(-)
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index fa8c0c75adf9..9831d25dd83e 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -19,6 +19,8 @@
#include
#include
#include
+#include
+#include
#define RNG_SEED_SIZE 128
@@ -116,7 +118,6 @@ static int do_get_kexec_buffer(const void *prop, int len,
unsigned long *addr,
return 0;
}
-#ifdef CONFIG_HAVE_IMA_KEXEC
static int __init get_kexec_buffer(const char *name, unsigned long *addr,
size_t *size)
{
@@ -151,6 +152,7 @@ static int __init get_kexec_buffer(const char *name,
unsigned long *addr,
return 0;
}
+#ifdef CONFIG_HAVE_IMA_KEXEC
/**
* ima_get_kexec_buffer - get IMA buffer from the previous kernel
* @addr: On successful return, set to point to the buffer contents.
@@ -239,7 +241,6 @@ static void remove_ima_buffer(void *fdt, int chosen_node)
remove_buffer(fdt, chosen_node, "linux,ima-kexec-buffer");
}
-#ifdef CONFIG_IMA_KEXEC
static int setup_buffer(void *fdt, int chosen_node, const char *name,
phys_addr_t addr, size_t size)
{
@@ -263,6 +264,7 @@ static int setup_buffer(void *fdt, int chosen_node, const
char *name,
}
+#ifdef CONFIG_IMA_KEXEC
/**
* setup_ima_buffer - add IMA buffer information to the fdt
* @image: kexec image being loaded.
@@ -285,6 +287,213 @@ static inline int setup_ima_buffer(const struct kimage
*image, void *fdt,
}
#endif /* CONFIG_IMA_KEXEC */
+/**
+ * tpm_get_kexec_buffer - get TPM log buffer from the previous kernel
+ * @phyaddr: On successful return, set to physical address of buffer
+ * @size: On successful return, set to the buffer size.
+ *
+ * Return: 0 on success, negative errno on error.
+ */
+static int __init tpm_get_kexec_buffer(phys_addr_t *phyaddr, size_t *size)
+{
+ unsigned long tmp_addr;
+ size_t tmp_size;
+ int ret;
+
+ ret = get_kexec_buffer("linux,tpm-kexec-buffer", _addr, _size);
+ if (ret)
+ return ret;
+
+ *phyaddr = (phys_addr_t)tmp_addr;
+ *size = tmp_size;
+
+ return 0;
+}
+
+/**
+ * tpm_of_remove_kexec_buffer - remove the linux,tpm-kexec-buffer node
+ */
+static int __init tpm_of_remove_kexec_buffer(void)
+{
+ struct property *prop;
+
+ prop = of_find_property(of_chosen, "linux,tpm-kexec-buffer", NULL);
+ if (!prop)
+ return -ENOENT;
+
+ return of_remove_property(of_chosen, prop);
+}
+
+/**
+ * remove_tpm_buffer - remove the TPM log buffer property and reservation from
@fdt
+ *
+ * @fdt: Flattened Device Tree to update
+ * @chosen_node: Offset to the chosen node in the device tree
+ *
+ * The TPM log measurement buffer is of no use to a subsequent kernel, so we
always
+ * remove it from the device tree.
+ */
+static void
[PATCH v9 0/4] tpm: Preserve TPM measurement log across kexec (ppc64)
The of-tree subsystem does not currently preserve the IBM vTPM 1.2 and vTPM 2.0 measurement logs across a kexec on PowerVM and PowerKVM. This series fixes this for the kexec_file_load() syscall using the flattened device tree (fdt) to carry the TPM measurement log's buffer across kexec. Stefan v9: - 2/4: Rebased on 6.3-rc7: call tpm_read_log_memory_region if -ENODEV returned v8: - Added Jarkko's, Coiby's, and Rob's tags - Rebase on v6.0-rc3 that absorbed 2 already upstreamed patches v7: - Added Nageswara's Tested-by tags - Added back original comment to inline function and removed Jarkko's R-b tag v6: - Add __init to get_kexec_buffer as suggested by Jonathan - Fixed issue detected by kernel test robot v5: - Rebased on 1 more patch that would otherwise create merge conflicts v4: - Rebased on 2 patches that would otherwise create merge conflicts; posting these patches in this series with several tags removed so krobot can test the series already - Changes to individual patches documented in patch descripitons v3: - Moved TPM Open Firmware related function to drivers/char/tpm/eventlog/tpm_of.c v2: - rearranged patches - fixed compilation issues for x86 Palmer Dabbelt (1): drivers: of: kexec ima: Support 32-bit platforms Stefan Berger (3): tpm: of: Make of-tree specific function commonly available of: kexec: Refactor IMA buffer related functions to make them reusable tpm/kexec: Duplicate TPM measurement log in of-tree for kexec drivers/char/tpm/eventlog/of.c | 30 +-- drivers/of/kexec.c | 336 - include/linux/kexec.h | 6 + include/linux/of.h | 6 + include/linux/tpm.h| 36 kernel/kexec_file.c| 6 + 6 files changed, 344 insertions(+), 76 deletions(-) base-commit: 6a8f57ae2eb07ab39a6f0ccad60c760743051026 -- 2.38.1
[Bug 217350] New: kdump kernel hangs in powerkvm guest
https://bugzilla.kernel.org/show_bug.cgi?id=217350 Bug ID: 217350 Summary: kdump kernel hangs in powerkvm guest Product: Platform Specific/Hardware Version: 2.5 Hardware: PPC-64 OS: Linux Status: NEW Severity: normal Priority: P3 Component: PPC-64 Assignee: platform_ppc...@kernel-bugs.osdl.org Reporter: pi...@redhat.com Regression: No Created attachment 304157 --> https://bugzilla.kernel.org/attachment.cgi?id=304157=edit The xml to configure the virtual machine This bug has been observed at least since kernel version 5.19. The kdump kernel command line: [0.00] Kernel command line: elfcorehdr=0x22c0 no_timer_check net.ifnames=0 console=tty0 console=hvc0,115200n8 irqpoll maxcpus=1 noirqdistrib reset_devices cgroup_disable=memory numa=off udev.children-max=2 ehea.use_mcs=0 panic=10 kvm_cma_resv_ratio=0 transparent_hugepage=never novmcoredd hugetlb_cma=0 Finally, the system hangs: [7.763260] virtio_blk virtio2: 32/0/0 default/read/poll queues [7.771391] virtio_blk virtio2: [vda] 20971520 512-byte logical blocks (10.7 GB/10.0 GiB) [ 68.398234] systemd-udevd[187]: virtio2: Worker [190] processing SEQNUM=1193 is taking a long time [ 188.398258] systemd-udevd[187]: virtio2: Worker [190] processing SEQNUM=1193 killed -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] ASoC: fsl_sai: Fix pins setting for i.MX8QM platform
SAI on i.MX8QM platform supports the data lines up to 4. So the pins
setting should be corrected to 4.
Fixes: eba0f0077519 ("ASoC: fsl_sai: Enable combine mode soft")
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_sai.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 07d13dca852e..abdaffb00fbd 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -1544,7 +1544,7 @@ static const struct fsl_sai_soc_data fsl_sai_imx8qm_data
= {
.use_imx_pcm = true,
.use_edma = true,
.fifo_depth = 64,
- .pins = 1,
+ .pins = 4,
.reg_offset = 0,
.mclk0_is_mclk1 = false,
.flags = 0,
--
2.25.1
Re: [PATCH v3 00/19] arch: Consolidate
Hi
Am 17.04.23 um 16:12 schrieb Arnd Bergmann:
On Mon, Apr 17, 2023, at 14:56, Thomas Zimmermann wrote:
Various architectures provide with helpers for fbdev
framebuffer devices. Share the contained code where possible. There
is already , which implements generic (as in
'empty') functions of the fbdev helpers. The header was added in
commit aafe4dbed0bf ("asm-generic: add generic versions of common
headers"), but never used.
Each per-architecture header file declares and/or implements fbdev
helpers and defines a preprocessor token for each. The generic
header then provides the remaining helpers. It works like the I/O
helpers in .
Looks all good to me,
Acked-by: Arnd Bergmann
Thanks a lot. I know that Helge wants to test the PARISC changes, so
I'll keep this series pending for a bit longer. I'd like to merge the
patches through the DRM tree, if no one objects.
Best regards
Thomas
Arnd
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v3 2/2] soc: fsl: qbman: Use raw spinlock for cgr_lock
On Tue, 2023-04-11 at 11:09 -0400, Sean Anderson wrote:
> Hi Crystal,
>
> On 4/4/23 12:04, Sean Anderson wrote:
> > On 4/4/23 11:33, Crystal Wood wrote:
> > > On Tue, 2023-04-04 at 10:55 -0400, Sean Anderson wrote:
> > >
> > > > @@ -1456,11 +1456,11 @@ static void tqm_congestion_task(struct
> > > > work_struct
> > > > *work)
> > > > union qm_mc_result *mcr;
> > > > struct qman_cgr *cgr;
> > > >
> > > > - spin_lock_irq(>cgr_lock);
> > > > + raw_spin_lock_irq(>cgr_lock);
> > > > qm_mc_start(>p);
> > > > qm_mc_commit(>p, QM_MCC_VERB_QUERYCONGESTION);
> > > > if (!qm_mc_result_timeout(>p, )) {
> > > > - spin_unlock_irq(>cgr_lock);
> > > > + raw_spin_unlock_irq(>cgr_lock);
> > >
> > > qm_mc_result_timeout() spins with a timeout of 10 ms which is very
> > > inappropriate for a raw lock. What is the actual expected upper bound?
> >
> > Hm, maybe we can move this qm_mc stuff outside cgr_lock? In most other
> > places they're called without cgr_lock, which implies that its usage
> > here is meant to synchronize against some other function.
>
> Do you have any suggestions here? I think this should really be handled
> in a follow-up patch. If you think this code is waiting too long in a raw
> spinlock, the existing code can wait just as long with IRQs disabled.
> This patch doesn't change existing system responsiveness.
Well, AFAICT it expands the situations in which it happens from configuration
codepaths to stuff like congestion handling. The proper fix would probably be
to use some mechanism other than smp_call_function_single() to run code on the
target cpu so that it can run with irqs enabled (or get confirmation that the
actual worst case is short enough), but barring that I guess at least
acknowledge the situation in a comment?
-Crystal
