* [PATCH v2 0/4] pinctrl: bcm2835: Support for wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Florian Fainelli, Linus Walleij, Rob Herring, Ray Jui,
Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Nicolas Saenz Julienne, Stefan Wahren, Geert Uytterhoeven,
Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
Hi Linus,
This patch series updates the bcm2835 pinctrl driver to support
the BCM7211 SoC which is quite similar to 2711 (Raspberry Pi 4)
except that it also supports wake-up interrupts.
Thanks!
Changes in v2:
- fixed patch #3 to reference the correct data structure (Stefan)
- fixed patch #4 to use conditional initialization and fetching of
interrupt resources to limit the memory overhead for non-7211 chips
Florian Fainelli (4):
dt-bindings: pinctrl: Document 7211 compatible for
brcm,bcm2835-gpio.txt
dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
pinctrl: bcm2835: Match BCM7211 compatible string
pinctrl: bcm2835: Add support for wake-up interrupts
.../bindings/pinctrl/brcm,bcm2835-gpio.txt | 5 +-
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 80 ++++++++++++++++++-
2 files changed, 83 insertions(+), 2 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: pinctrl: Document optional BCM7211 wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-1-f.fainelli@gmail.com>
BCM7211 supports wake-up interrupts in the form of optional interrupt
lines, one per bank, plus the "all banks" interrupt line.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
index dfc67b90591c..5682b2010e50 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt
@@ -16,7 +16,9 @@ Required properties:
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- interrupts : The interrupt outputs from the controller. One interrupt per
- individual bank followed by the "all banks" interrupt.
+ individual bank followed by the "all banks" interrupt. For BCM7211, an
+ additional set of per-bank interrupt line and an "all banks" wake-up
+ interrupt may be specified.
- interrupt-controller: Marks the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
The first cell is the GPIO number.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ci: run SELinux kernel test suite
From: William Roberts @ 2020-05-29 19:17 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: Paul Moore, SElinux list, William Roberts
In-Reply-To: <CAFqZXNt_mQsbS_Yzd7AT0_XUDzGs_u6b6UTb3DPa8XzsbhqrfQ@mail.gmail.com>
On Fri, May 29, 2020 at 1:43 PM Ondrej Mosnacek <omosnace@redhat.com> wrote:
>
> Apologies for getting back to this so late... Just some small nitpicks.
>
> On Wed, May 20, 2020 at 6:34 PM <bill.c.roberts@gmail.com> wrote:
> > From: William Roberts <william.c.roberts@intel.com>
> >
> > The current Travis CI runs the userspace tooling and libraries against
> > policy files, but cannot test against an SELinux enabled kernel. Thus,
> > some tests are not being done in the CI. Travis, unfortunately only
> > provides Ubuntu images, so in order to run against a modern distro with
> > SELinux in enforcing mode, we need to launch a KVM with something like
> > Fedora.
> >
> > This patch enables this support by launching a Fedora32 Cloud Image with
> > the SELinux userspace library passed on from the Travis clone, it then
> > builds and replaces the current SELinux bits on the Fedora32 image and
> > runs the SELinux testsuite.
> >
> > Signed-off-by: William Roberts <william.c.roberts@intel.com>
> > ---
> > .travis.yml | 8 +++
> > scripts/ci/README.md | 8 +++
> > scripts/ci/fedora-test-runner.sh | 89 ++++++++++++++++++++++++
> > scripts/ci/travis-kvm-setup.sh | 113 +++++++++++++++++++++++++++++++
> > 4 files changed, 218 insertions(+)
> > create mode 100644 scripts/ci/README.md
> > create mode 100755 scripts/ci/fedora-test-runner.sh
> > create mode 100755 scripts/ci/travis-kvm-setup.sh
> >
> [...]
> > diff --git a/scripts/ci/fedora-test-runner.sh b/scripts/ci/fedora-test-runner.sh
> > new file mode 100755
> > index 000000000000..14bcf5fc469d
> > --- /dev/null
> > +++ b/scripts/ci/fedora-test-runner.sh
> > @@ -0,0 +1,89 @@
> > +#!/usr/bin/env bash
> > +
> > +set -ev
> > +
> > +# CI Debug output if things go squirrely.
> > +getenforce
> > +id -Z
> > +nproc
> > +pwd
>
> I'd add also "uname -r" here to dump the running kernel version (will
> probably be also printed later somewhere, but better to have it also
> in one place with the other debug info).
>
> > +
> > +# Turn off enforcing for the setup to prevent any weirdness from breaking
> > +# the CI.
> > +setenforce 0
> > +
> > +dnf clean all -y
> > +dnf install -y \
> [...]
> > diff --git a/scripts/ci/travis-kvm-setup.sh b/scripts/ci/travis-kvm-setup.sh
> > new file mode 100755
> > index 000000000000..66606e9d4a5b
> > --- /dev/null
> > +++ b/scripts/ci/travis-kvm-setup.sh
> > @@ -0,0 +1,113 @@
> > +#!/usr/bin/env bash
> > +
> > +set -ev
> > +
> > +TEST_RUNNER="scripts/ci/fedora-test-runner.sh"
> > +
> > +#
> > +# Travis gives us 7.5GB of RAM and two cores:
> > +# https://docs.travis-ci.com/user/reference/overview/
> > +#
> > +MEMORY=4096
> > +VCPUS=2
>
> Why not "VCPUS=$(nproc)"?
+1: Initially I just had this set to what travis provides. I don't
know why I didn't do that.
>
> > +
> > +# Install these here so other builds don't have to wait on these deps to download and install
> > +sudo apt-get install qemu-kvm libvirt-bin virtinst bridge-utils cpu-checker libguestfs-tools
> > +
> > +sudo usermod -a -G kvm,libvirt,libvirt-qemu $USER
> > +
> > +# Verify that KVM is working, useful if Travis every changes anything.
>
> s/every/ever/
+1
>
> > +kvm-ok
> > +
> > +sudo systemctl enable libvirtd
> > +sudo systemctl start libvirtd
> > +
> > +# Set up a key so we can ssh into the VM
> > +ssh-keygen -N "" -f "$HOME/.ssh/id_rsa"
> > +
> > +#
> > +# Get the Fedora Cloud Image, It is a base image that small and ready to go, extract it and modify it with virt-sysprep
> > +# - https://alt.fedoraproject.org/en/verify.html
> > +cd $HOME
> > +wget https://download.fedoraproject.org/pub/fedora/linux/releases/32/Cloud/x86_64/images/Fedora-Cloud-Base-32-1.6.x86_64.raw.xz
>
> I'd suggest extracting the Fedora release version (32) + the image
> version (1.6) into variables, so they can be easily bumped later.
Sure, I forget why I ended up not doing it this way. I remember it
being late at night, and cursing for some reason.
>
> > +
> > +# Verify the image
> > +curl https://getfedora.org/static/fedora.gpg | gpg --import
> > +wget https://getfedora.org/static/checksums/Fedora-Cloud-32-1.6-x86_64-CHECKSUM
> > +gpg --verify-files *-CHECKSUM
> > +sha256sum --ignore-missing -c *-CHECKSUM
> > +
> > +# Extract the image
> > +unxz -T0 Fedora-Cloud-Base-32-1.6.x86_64.raw.xz
> > +
> > +# Search is needed for $HOME so virt service can access the image file.
> > +chmod a+x $HOME
> > +
> > +#
> > +# Modify the virtual image to:
> > +# - Enable a login, we just use root
> > +# - Enable passwordless login
> > +# - Force a relabel to fix labels on ssh keys
> > +#
> > +sudo virt-sysprep -a "$HOME/Fedora-Cloud-Base-32-1.6.x86_64.raw" \
> > + --root-password password:123456 \
>
> Do you need to set the password when you use an SSH key to login?
Yeah the account is disabled unless you do this. Plus it was helpful when
using the scripts locally and using virsh console
>
> > + --hostname fedoravm \
> > + --append-line '/etc/ssh/sshd_config:PermitRootLogin yes' \
> > + --append-line '/etc/ssh/sshd_config:PubkeyAuthentication yes' \
> > + --mkdir /root/.ssh \
> > + --upload "$HOME/.ssh/id_rsa.pub:/root/.ssh/authorized_keys" \
> > + --chmod '0600:/root/.ssh/authorized_keys' \
> > + --run-command 'chown root:root /root/.ssh/authorized_keys' \
>
> Could these be replaced with just "--ssh-inject root"?
No, and I went through immense pain trying to get it to work. The
reason is that the tool
will dump it under /home/root instead of /root. So it won't get picked
up without some
other magic anyways.
>
> > + --copy-in "$TRAVIS_BUILD_DIR:/root" \
> > + --network \
> > + --selinux-relabel
> > +
> > +#
> > +# Now we create a domain by using virt-install. This not only creates the domain, but runs the VM as well
> > +# It should be ready to go for ssh, once ssh starts.
> > +#
> > +sudo virt-install \
> > + --name fedoravm \
> > + --memory $MEMORY \
> > + --vcpus $VCPUS \
> > + --disk "$HOME/Fedora-Cloud-Base-32-1.6.x86_64.raw" \
> > + --import --noautoconsole
> > +
> > +#
> > +# Here comes the tricky part, we have to figure out when the VM comes up AND we need the ip address for ssh. So we
> > +# can check the net-dhcp leases, for our host. We have to poll, and we will poll for up 3 minutes in 6 second
> > +# intervals, so 30 poll attempts (0-29 inclusive). I don't know of a better way to do this.
> > +#
> > +# We have a full reboot + relabel, so first sleep gets us close
> > +#
> > +sleep 30
> > +for i in $(seq 0 29); do
> > + echo "loop $i"
> > + sleep 6s
> > + # Get the leases, but tee it so it's easier to debug
> > + sudo virsh net-dhcp-leases default | tee dhcp-leases.txt
> > +
> > + # get our ipaddress
> > + ipaddy=$(grep fedoravm dhcp-leases.txt | awk {'print $5'} | cut -d'/' -f 1-1)
>
> Looks cleaner this way:
> [...] | awk '{ print $5 }' | cut -d / -f 1)
>
> > + if [ -n "$ipaddy" ]; then
> > + # found it, we're done looking, print it for debug logs
> > + echo "ipaddy: $ipaddy"
> > + break
> > + fi
> > + # it's empty/not found, loop back and try again.
> > +done
> > +
> > +# Did we find it? If not die.
> > +if [ -z "$ipaddy" ]; then
> > + echo "ipaddy zero length, exiting with error 1"
> > + exit 1
> > +fi
> > +
> > +#
> > +# Great we have a host running, ssh into it. We specify -o so
> > +# we don't get blocked on asking to add the servers key to
> > +# our known_hosts.
> > +#
> > +ssh -tt -o StrictHostKeyChecking=no -o LogLevel=QUIET "root@$ipaddy" "/root/selinux/$TEST_RUNNER"
> > +
> > +exit 0
> > --
> > 2.17.1
>
Thanks Ondrej.
Bill
^ permalink raw reply
* [PATCH v2 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-1-f.fainelli@gmail.com>
The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
BCM2711 SoC, match the compatible string and use the correct set of
options.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 06bd2b70af3c..1b00d93aa66e 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -1137,6 +1137,10 @@ static const struct of_device_id bcm2835_pinctrl_match[] = {
.compatible = "brcm,bcm2711-gpio",
.data = &bcm2711_plat_data,
},
+ {
+ .compatible = "brcm,bcm7211-gpio",
+ .data = &bcm2711_plat_data,
+ },
{}
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v6 02/11] dt-bindings: i2c: Convert DW I2C slave to the DW I2C master example
From: Rob Herring @ 2020-05-29 19:17 UTC (permalink / raw)
To: Serge Semin
Cc: Serge Semin, linux-i2c, Rob Herring, Mika Westerberg,
Alexey Malahov, devicetree, Jarkko Nikula, Thomas Bogendoerfer,
Wolfram Sang, linux-kernel, linux-mips, Andy Shevchenko
In-Reply-To: <20200528093322.23553-3-Sergey.Semin@baikalelectronics.ru>
On Thu, 28 May 2020 12:33:12 +0300, Serge Semin wrote:
> dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> i2c "reg" property. If dtc finds an i2c-slave sub-node having an address
> higher than ten-bits wide it'll print an ugly warning:
>
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
>
> In order to silence dtc up let's replace the corresponding DT binding
> example with a normal DW I2C master mode-based one. It's done by clearing
> the I2C_OWN_SLAVE_ADDRESS bit in the reg property and converting the
> sub-node to be compatible with normal EEPROM like "atmel,24c02".
>
> Just revert this commit when dtc is fixed.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Rob, even though you asked for such modification, it might be a better to
> just ignore the warning until dtc is properly fixed. Andy and me agree
> with that. If you are also on the same side with us, just explicitly nack
> this patch so Jarkko or Wolfram would ignore it when merging in the series.
>
> Changelog v3:
> - This is a new patch created as a result of the Rob request to remove
> the EEPROM-slave bit setting in the DT binndings example until the dtc
> is fixed.
>
> Changelog v6:
> - Replace the "linux,slave-24c02" compatible string with "atmel,24c02" one
> so the example would be perceived as a normal DW I2C master mode.
> ---
> .../devicetree/bindings/i2c/snps,designware-i2c.yaml | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v2 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
From: Florian Fainelli @ 2020-05-29 19:15 UTC (permalink / raw)
To: linux-kernel
Cc: Stefan Wahren,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Florian Fainelli, Geert Uytterhoeven, Scott Branden, Ray Jui,
Linus Walleij, Matti Vaittinen, open list:PIN CONTROL SUBSYSTEM,
Rob Herring,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
Nicolas Saenz Julienne,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20200529191522.27938-1-f.fainelli@gmail.com>
Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to
specifically treat the GPIO interrupts during suspend and resume, and
simply implement an irq_set_wake() callback that is responsible for
enabling the parent wake-up interrupt as a wake-up interrupt.
To avoid allocating unnecessary resources for other chips, the wake-up
interrupts are only initialized if we have a brcm,bcm7211-gpio
compatibility string.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pinctrl/bcm/pinctrl-bcm2835.c | 76 ++++++++++++++++++++++++++-
1 file changed, 75 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 1b00d93aa66e..1fbf067a3eed 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -19,6 +19,7 @@
#include <linux/irq.h>
#include <linux/irqdesc.h>
#include <linux/init.h>
+#include <linux/interrupt.h>
#include <linux/of_address.h>
#include <linux/of.h>
#include <linux/of_irq.h>
@@ -76,6 +77,7 @@
struct bcm2835_pinctrl {
struct device *dev;
void __iomem *base;
+ int *wake_irq;
/* note: locking assumes each bank will have its own unsigned long */
unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
@@ -435,6 +437,11 @@ static void bcm2835_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(host_chip, desc);
}
+static irqreturn_t bcm2835_gpio_wake_irq_handler(int irq, void *dev_id)
+{
+ return IRQ_HANDLED;
+}
+
static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
unsigned reg, unsigned offset, bool enable)
{
@@ -634,6 +641,34 @@ static void bcm2835_gpio_irq_ack(struct irq_data *data)
bcm2835_gpio_set_bit(pc, GPEDS0, gpio);
}
+static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int on)
+{
+ struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
+ struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
+ unsigned gpio = irqd_to_hwirq(data);
+ unsigned int irqgroup;
+ int ret = -EINVAL;
+
+ if (!pc->wake_irq)
+ return ret;
+
+ if (gpio <= 27)
+ irqgroup = 0;
+ else if (gpio >= 28 && gpio <= 45)
+ irqgroup = 1;
+ else if (gpio >= 46 && gpio <= 53)
+ irqgroup = 2;
+ else
+ return ret;
+
+ if (on)
+ ret = enable_irq_wake(pc->wake_irq[irqgroup]);
+ else
+ ret = disable_irq_wake(pc->wake_irq[irqgroup]);
+
+ return ret;
+}
+
static struct irq_chip bcm2835_gpio_irq_chip = {
.name = MODULE_NAME,
.irq_enable = bcm2835_gpio_irq_enable,
@@ -642,6 +677,8 @@ static struct irq_chip bcm2835_gpio_irq_chip = {
.irq_ack = bcm2835_gpio_irq_ack,
.irq_mask = bcm2835_gpio_irq_disable,
.irq_unmask = bcm2835_gpio_irq_enable,
+ .irq_set_wake = bcm2835_gpio_irq_set_wake,
+ .flags = IRQCHIP_MASK_ON_SUSPEND,
};
static int bcm2835_pctl_get_groups_count(struct pinctrl_dev *pctldev)
@@ -1154,6 +1191,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
struct resource iomem;
int err, i;
const struct of_device_id *match;
+ int is_7211 = 0;
BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_pins) != BCM2711_NUM_GPIOS);
BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_groups) != BCM2711_NUM_GPIOS);
@@ -1180,6 +1218,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
return -EINVAL;
pdata = match->data;
+ is_7211 = of_device_is_compatible(np, "brcm,bcm7211-gpio");
pc->gpio_chip = *pdata->gpio_chip;
pc->gpio_chip.parent = dev;
@@ -1214,6 +1253,15 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
GFP_KERNEL);
if (!girq->parents)
return -ENOMEM;
+
+ if (is_7211) {
+ pc->wake_irq = devm_kcalloc(dev, BCM2835_NUM_IRQS,
+ sizeof(*pc->wake_irq),
+ GFP_KERNEL);
+ if (!pc->wake_irq)
+ return -ENOMEM;
+ }
+
/*
* Use the same handler for all groups: this is necessary
* since we use one gpiochip to cover all lines - the
@@ -1221,8 +1269,34 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
* bank that was firing the IRQ and look up the per-group
* and bank data.
*/
- for (i = 0; i < BCM2835_NUM_IRQS; i++)
+ for (i = 0; i < BCM2835_NUM_IRQS; i++) {
+ int len;
+ char *name;
+
girq->parents[i] = irq_of_parse_and_map(np, i);
+ if (!is_7211)
+ continue;
+
+ /* Skip over the all banks interrupts */
+ pc->wake_irq[i] = irq_of_parse_and_map(np, i +
+ BCM2835_NUM_IRQS + 1);
+
+ len = strlen(dev_name(pc->dev)) + 16;
+ name = devm_kzalloc(pc->dev, len, GFP_KERNEL);
+ if (!name)
+ return -ENOMEM;
+
+ snprintf(name, len, "%s:bank%d", dev_name(pc->dev), i);
+
+ /* These are optional interrupts */
+ err = devm_request_irq(dev, pc->wake_irq[i],
+ bcm2835_gpio_wake_irq_handler,
+ IRQF_SHARED, name, pc);
+ if (err)
+ dev_warn(dev, "unable to request wake IRQ %d\n",
+ pc->wake_irq[i]);
+ }
+
girq->default_type = IRQ_TYPE_NONE;
girq->handler = handle_level_irq;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v3 00/13] Remove FMR support from RDMA drivers
From: Jason Gunthorpe @ 2020-05-29 19:17 UTC (permalink / raw)
To: linux-rdma, netdev
Cc: Ariel Elior, aron.silverton, Bernard Metzler, Bart Van Assche,
Dennis Dalessandro, Devesh Sharma, Faisal Latif, Gal Pressman,
Israel Rukshin, Leon Romanovsky, Max Gurtovoy, Mike Marciniszyn,
Michal Kalderon, oren, Sagi Grimberg, santosh.shilimkar,
Selvin Xavier, Shiraz Saleem, shlomin, Somnath Kotur,
Sriharsha Basavapatna, vladimirk, Yishai Hadas
In-Reply-To: <0-v3-f58e6669d5d3+2cf-fmr_removal_jgg@mellanox.com>
On Thu, May 28, 2020 at 04:45:42PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe <jgg@mellanox.com>
>
> This series removes the support for FMR mode to register memory. This
> ancient mode is unsafe (rkeys that are usually exposed for caching
> purposes and the API is limited to page granularity mappings) and not
> maintained/tested in the last few years. It also doesn't have any
> reasonable advantage over other memory registration methods such as
> FRWR (that is implemented in all the recent RDMA adapters). This series
> should be reviewed and approved by the maintainer of the effected drivers
> and I suggest to test it as well.
>
> Changes from V2:
> - Removed more occurances of _fmr
> - Remove max_map_per_fmr device attribute
> - Remove max_fmr device attribute
> - Remove additional dead code from bnxt_re and i40iw
> - Revised RDS to not use ib_fmr_attr or other fmr things
> - Rebased on RDMA for-next
> Changes from V1:
> https://lore.kernel.org/linux-rdma/20200527094634.24240-1-maxg@mellanox.com/
> - added "RDMA/mlx5: Remove FMR leftovers" (from GalP)
> - rebased on top of "Linux 5.7-rc7"
> - added "Reviewed-by" Bart signature for SRP
>
> Cc: shlomin@mellanox.com
> Cc: vladimirk@mellanox.com
> Cc: oren@mellanox.com
>
> Gal Pressman (1):
> RDMA/mlx5: Remove FMR leftovers
>
> Israel Rukshin (1):
> RDMA/iser: Remove support for FMR memory registration
>
> Jason Gunthorpe (4):
> RDMA/bnxt_re: Remove FMR leftovers
> RDMA/i40iw: Remove FMR leftovers
> RDMA: Remove 'max_fmr'
> RDMA: Remove 'max_map_per_fmr'
>
> Max Gurtovoy (7):
> RDMA/srp: Remove support for FMR memory registration
> RDMA/rds: Remove FMR support for memory registration
> RDMA/core: Remove FMR pool API
> RDMA/mlx4: Remove FMR support for memory registration
> RDMA/mthca: Remove FMR support for memory registration
> RDMA/rdmavt: Remove FMR memory registration
> RDMA/core: Remove FMR device ops
Applied to for-next
Jason
^ permalink raw reply
* Re: [net-next 00/17][pull request] Intel Wired LAN Driver Updates 2020-05-28
From: David Miller @ 2020-05-29 19:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann
In-Reply-To: <20200529044004.3725307-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 28 May 2020 21:39:47 -0700
> This series contains updates to e1000, e1000e, igc, igb, ixgbe and i40e.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [Bridge] [PATCH net-next 2/2] bridge: mrp: Add support for role MRA
From: Jakub Kicinski @ 2020-05-29 19:18 UTC (permalink / raw)
To: Horatiu Vultur
Cc: ivecera, jiri, nikolay, netdev, roopa, bridge, linux-kernel,
UNGLinuxDriver, davem
In-Reply-To: <20200529100514.920537-3-horatiu.vultur@microchip.com>
On Fri, 29 May 2020 10:05:14 +0000 Horatiu Vultur wrote:
> A node that has the MRA role, it can behave as MRM or MRC.
>
> Initially it starts as MRM and sends MRP_Test frames on both ring ports.
> If it detects that there are MRP_Test send by another MRM, then it
> checks if these frames have a lower priority than itself. In this case
> it would send MRP_Nack frames to notify the other node that it needs to
> stop sending MRP_Test frames.
> If it receives a MRP_Nack frame then it stops sending MRP_Test frames
> and starts to behave as a MRC but it would continue to monitor the
> MRP_Test frames send by MRM. If at a point the MRM stops to send
> MRP_Test frames it would get the MRM role and start to send MRP_Test
> frames.
>
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
^ permalink raw reply
* Re: [PATCH net-next 2/2] bridge: mrp: Add support for role MRA
From: Jakub Kicinski @ 2020-05-29 19:18 UTC (permalink / raw)
To: Horatiu Vultur
Cc: nikolay, roopa, jiri, ivecera, davem, UNGLinuxDriver, netdev,
linux-kernel, bridge
In-Reply-To: <20200529100514.920537-3-horatiu.vultur@microchip.com>
On Fri, 29 May 2020 10:05:14 +0000 Horatiu Vultur wrote:
> A node that has the MRA role, it can behave as MRM or MRC.
>
> Initially it starts as MRM and sends MRP_Test frames on both ring ports.
> If it detects that there are MRP_Test send by another MRM, then it
> checks if these frames have a lower priority than itself. In this case
> it would send MRP_Nack frames to notify the other node that it needs to
> stop sending MRP_Test frames.
> If it receives a MRP_Nack frame then it stops sending MRP_Test frames
> and starts to behave as a MRC but it would continue to monitor the
> MRP_Test frames send by MRM. If at a point the MRM stops to send
> MRP_Test frames it would get the MRM role and start to send MRP_Test
> frames.
>
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
net/bridge/br_mrp.c:542:20: warning: cast to restricted __be16
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: i2c: dw: Add Baikal-T1 SoC I2C controller
From: Rob Herring @ 2020-05-29 19:18 UTC (permalink / raw)
To: Serge Semin
Cc: Rob Herring, Serge Semin, Andy Shevchenko, Thomas Bogendoerfer,
linux-mips, linux-i2c, Jarkko Nikula, linux-kernel, devicetree,
Wolfram Sang, Alexey Malahov, Mika Westerberg
In-Reply-To: <20200528093322.23553-4-Sergey.Semin@baikalelectronics.ru>
On Thu, 28 May 2020 12:33:13 +0300, Serge Semin wrote:
> Add the "baikal,bt1-sys-i2c" compatible string to the DW I2C binding. Even
> though the corresponding node is supposed to be a child of the Baikal-T1
> System Controller, its reg property is left required for compatibility.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> Cc: linux-mips@vger.kernel.org
>
> ---
>
> Changelog v2:
> - Make the reg property being optional if it's Baikal-T1 System I2C DT
> node.
>
> Changelog v3:
> - Get back the reg property being mandatory even if it's Baikal-T1 System
> I2C DT node. Rob says it has to be in the DT node if there is a
> dedicated registers range in the System Controller registers space.
> ---
> Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver
From: santosh.shilimkar @ 2020-05-29 19:19 UTC (permalink / raw)
To: Arnd Bergmann, Grygorii Strashko
Cc: Nishanth Menon, DTML, Dave Gerlach, Lokesh Vutla, Sekhar Nori,
linux-kernel@vger.kernel.org, Tero Kristo, Rob Herring,
Santosh Shilimkar, Linux ARM
In-Reply-To: <CAK8P3a31DYOn1TyjxCYM7ebc9nL5EFKsNpSHkq55bG54Bns+MA@mail.gmail.com>
On 5/29/20 11:34 AM, Arnd Bergmann wrote:
> On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 12/05/2020 15:34, Grygorii Strashko wrote:
>
>>> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
>>> drivers/soc/ti/Kconfig | 10 ++
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
>>> 4 files changed, 203 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>>> create mode 100644 drivers/soc/ti/k3-socinfo.c
>>>
>>
>> Any chances you can pick this up?
>
> I merged a version of this driver from Santosh's pull request into the
> arm/drviers tree yesterday.
>
> Is there something missing?
>
Nope. I was going to reply on the thread but missed it.
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: clean up kernel_{read,write} & friends v2
From: Linus Torvalds @ 2020-05-29 19:19 UTC (permalink / raw)
To: David Laight
Cc: Casey Schaufler, David Howells, Christoph Hellwig, Al Viro,
Ian Kent, Linux Kernel Mailing List, linux-fsdevel, LSM List,
NetFilter
In-Reply-To: <3aea7a1c10e94ea2964fa837ae7d8fe2@AcuMS.aculab.com>
On Fri, May 29, 2020 at 6:08 AM David Laight <David.Laight@aculab.com> wrote:
>
> A wide monitor is for looking at lots of files.
Not necessarily.
Excessive line breaks are BAD. They cause real and every-day problems.
They cause problems for things like "grep" both in the patterns and in
the output, since grep (and a lot of other very basic unix utilities)
is fundamentally line-based.
So the fact is, many of us have long long since skipped the whole
"80-column terminal" model, for the same reason that we have many more
lines than 25 lines visible at a time.
And honestly, I don't want to see patches that make the kernel reading
experience worse for me and likely for the vast majority of people,
based on the argument that some odd people have small terminal
windows.
If you or Christoph have 80 character lines, you'll get possibly ugly
wrapped output. Tough. That's _your_ choice. Your hardware limitations
shouldn't be a pain for the rest of us.
Longer lines are fundamentally useful. My monitor is not only a lot
wider than it is tall, my fonts are universally narrower than they are
tall. Long lines are natural.
When I tile my terminal windows on my display, I can have 6 terminals
visible at one time, and that's because I have them three wide. And I
could still fit 80% of a fourth one side-by-side.
And guess what? That's with my default "100x50" terminal window (go to
your gnome terminal settings, you'll find that the 80x25 thing is just
an initial default that you can change), not with some 80x25 one. And
that's with a font that has anti-aliasing and isn't some pixelated
mess.
And most of my terminals actually end up being dragged wider and
taller than that. I checked, and my main one is 142x76 characters
right now, because it turns out that wider (and taller) terminals are
useful not just for source code.
Have you looked at "ps ax" output lately? Or used "top"? Or done "git
diff --stat" or any number of things where it turns out that 80x25 is
really really limiting, and is simply NO LONGER RELEVANT to most of
us.
So no. I do not care about somebody with a 80x25 terminal window
getting line wrapping.
For exactly the same reason I find it completely irrelevant if
somebody says that their kernel compile takes 10 hours because they
are doing kernel development on a Raspberry PI with 4GB of RAM.
People with restrictive hardware shouldn't make it more inconvenient
for people who have better resources. Yes, we'll accommodate things to
within reasonable limits. But no, 80-column terminals in 2020 isn't
"reasonable" any more as far as I'm concerned. People commonly used
132-column terminals even back in the 80's, for chrissake, don't try
to make 80 columns some immovable standard.
If you choose to use a 80-column terminal, you can live with the line
wrapping. It's just that simple.
And longer lines are simply useful. Part of that is that we aren't
programming in the 80's any more, and our source code is fundamentally
wider as a result.
Yes, local iteration variables are still called 'i', because more
context just isn't helpful for some anonymous counter. Being concise
is still a good thing, and overly verbose names are not inherently
better.
But still - it's entirely reasonable to have variable names that are
10-15 characters and it makes the code more legible. Writing things
out instead of using abbreviations etc.
And yes, we do use wide tabs, because that makes indentation something
you can visually see in the structure at a glance and on a
whole-function basis, rather than something you have to try to
visually "line up" things for or count spaces.
So we have lots of fairly fundamental issues that fairly easily make
for longer lines in many circumstances.
And yes, we do line breaks at some point. But there really isn't any
reason to make that point be 80 columns any more.
Linus
^ permalink raw reply
* Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver
From: santosh.shilimkar @ 2020-05-29 19:19 UTC (permalink / raw)
To: Arnd Bergmann, Grygorii Strashko
Cc: Santosh Shilimkar, Tero Kristo, Rob Herring, Lokesh Vutla, DTML,
Dave Gerlach, Sekhar Nori, Linux ARM,
linux-kernel@vger.kernel.org, Nishanth Menon
In-Reply-To: <CAK8P3a31DYOn1TyjxCYM7ebc9nL5EFKsNpSHkq55bG54Bns+MA@mail.gmail.com>
On 5/29/20 11:34 AM, Arnd Bergmann wrote:
> On Fri, May 29, 2020 at 8:22 PM Grygorii Strashko
> <grygorii.strashko@ti.com> wrote:
>> On 12/05/2020 15:34, Grygorii Strashko wrote:
>
>>> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
>>> drivers/soc/ti/Kconfig | 10 ++
>>> drivers/soc/ti/Makefile | 1 +
>>> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
>>> 4 files changed, 203 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
>>> create mode 100644 drivers/soc/ti/k3-socinfo.c
>>>
>>
>> Any chances you can pick this up?
>
> I merged a version of this driver from Santosh's pull request into the
> arm/drviers tree yesterday.
>
> Is there something missing?
>
Nope. I was going to reply on the thread but missed it.
Regards,
Santosh
^ permalink raw reply
* Re: Git fetches whole repository and not just latest
From: Jonathan Nieder @ 2020-05-29 19:20 UTC (permalink / raw)
To: Andy Shevchenko; +Cc: git, Konstantin Ryabitsev, Joseph Smidt, Anders Kaseorg
In-Reply-To: <CAHp75VdTX=pJw6r=H=qfaDcv07n69uGQQ0TwrR0bACAx-OQAXQ@mail.gmail.com>
Andy Shevchenko wrote:
> On Fri, May 29, 2020 at 8:29 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>> What Git version are you using?
>
> git version 2.26.2
Thanks, makes sense.
>> Can you test 2.27.0-rc2?
>
> Is there any deb package?
Yes, you can use the package from Debian unstable or experimental
(https://tracker.debian.org/pkg/git).
If you're on Ubuntu, you can use
https://launchpad.net/~git-core/+archive/ubuntu/candidate once it
updates (cc-ing the maintainers of the PPA in case they want to
comment on when that will be --- e.g. Git 2.27 is planned to come
out this Monday).
Thanks,
Jonathan
^ permalink raw reply
* [PATCH 05/10] core: extend struct driver_info to point to device
From: Walter Lozano @ 2020-05-29 19:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAPnjgZ3WEhYwpn=k7xzy1xSi0_t8TyxVH=RMNYKe8g1FJ8f8ig@mail.gmail.com>
Hi Simon,
On 29/5/20 16:00, Simon Glass wrote:
> Hi Walter,
>
> On Fri, 29 May 2020 at 12:56, Walter Lozano <walter.lozano@collabora.com> wrote:
>>
>> On 29/5/20 15:15, Walter Lozano wrote:
>>> Currently when creating an U_BOOT_DEVICE entry a struct driver_info
>>> is declared, which contains the data needed to instantiate the device.
>>> However, the actual device is created at runtime and there is no proper
>>> way to get the device based on its struct driver_info.
>>>
>>> This patch extends struct driver_info adding a pointer to udevice which
>>> is populated during the bind process, allowing to generate a set of
>>> functions to get the device based on its struct driver_info.
>>>
>>> Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
>>> ---
>>> drivers/core/device.c | 26 +++++++++++++++++++++++---
>>> drivers/core/root.c | 4 ++++
>>> include/dm/device.h | 14 ++++++++++++++
>>> include/dm/platdata.h | 14 ++++++++++++++
>>> 4 files changed, 55 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/core/device.c b/drivers/core/device.c
>>> index a0ad080aaf..5adbc30849 100644
>>> --- a/drivers/core/device.c
>>> +++ b/drivers/core/device.c
>>> @@ -250,6 +250,7 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
>>> {
>>> struct driver *drv;
>>> uint platdata_size = 0;
>>> + int ret = 0;
>>>
>>> drv = lists_driver_lookup_name(info->name);
>>> if (!drv)
>>> @@ -260,9 +261,16 @@ int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
>>> #if CONFIG_IS_ENABLED(OF_PLATDATA)
>>> platdata_size = info->platdata_size;
>>> #endif
>>> - return device_bind_common(parent, drv, info->name,
>>> - (void *)info->platdata, 0, ofnode_null(), platdata_size,
>>> - devp);
>>> + ret = device_bind_common(parent, drv, info->name,
>>> + (void *)info->platdata, 0, ofnode_null(),
>>> + platdata_size, devp);
>>> + if (ret)
>>> + return ret;
>>> +#if CONFIG_IS_ENABLED(OF_PLATDATA)
>>> + info->dev = *devp;
>>> +#endif
>> I have tried to test this using sandbox_spl_defconfig but I've received
>> a segmentation fault when trying to update info->dev, however this code
>> works on iMX6.
>>
>> Could it be some kind of protection? Any thoughts?
> Yes, see u-boot-dm/dtoc-working - arch/sandbox/cpu/u-boot-spl.lds has
> an attempt to move some of the list stuff into the data region.
Thanks for confirmed it and also for the quick response. I'm about to
start a deeper review to your work about tiny-dm now.
Regards,
Walter
^ permalink raw reply
* Re: [PATCH net-next v4 3/4] dt-bindings: net: Add RGMII internal delay for DP83869
From: Dan Murphy @ 2020-05-29 19:20 UTC (permalink / raw)
To: Rob Herring
Cc: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200529190356.GA2758033@bogus>
Rob
On 5/29/20 2:03 PM, Rob Herring wrote:
> On Wed, May 27, 2020 at 11:49:33AM -0500, Dan Murphy wrote:
>> Add the internal delay values into the header and update the binding
>> with the internal delay properties.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> .../devicetree/bindings/net/ti,dp83869.yaml | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/ti,dp83869.yaml b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> index 5b69ef03bbf7..2971dd3fc039 100644
>> --- a/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> +++ b/Documentation/devicetree/bindings/net/ti,dp83869.yaml
>> @@ -64,6 +64,20 @@ properties:
>> Operational mode for the PHY. If this is not set then the operational
>> mode is set by the straps. see dt-bindings/net/ti-dp83869.h for values
>>
>> + rx-internal-delay-ps:
>> + $ref: "#/properties/rx-internal-delay-ps"
> This just creates a circular reference which probably blows up.
dt_binding_check did not have an issue with this.
But I will remove it
Dan
^ permalink raw reply
* Re: Lost PCIe PME after a914ff2d78ce ("PCI/ASPM: Don't select CONFIG_PCIEASPM by default")
From: Bjorn Helgaas @ 2020-05-29 19:21 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, Rafael J. Wysocki,
linux-kernel
In-Reply-To: <e66a6749-29a1-af23-6d07-6b3c4fd45220@gmail.com>
[+cc Rafael, linux-kernel]
On Fri, May 29, 2020 at 08:50:46PM +0200, Heiner Kallweit wrote:
> On 28.05.2020 23:44, Heiner Kallweit wrote:
> > For whatever reason with this change (and losing ASPM control) I also
> > loose the PCIe PME interrupts. This prevents my network card from
> > resuming from runtime-suspend.
> > Reverting the change brings back ASPM control and the PCIe PME irq's.
> >
> > Affected system is a Zotac MiniPC with a N3450 CPU:
> > PCI bridge: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series PCI Express Port A #1 (rev fb)
> >
> I checked a little bit further and w/o ASPM control the root ports
> don't have the PME service bit set in their capabilities.
> Not sure whether this is a chipset bug or whether there's a better
> explanation. However more chipsets may have such a behavior.
Hmm. Is the difference simply changing the PCIEASPM config symbol, or
are you booting with command-line arguments like "pcie_aspm=off"?
What's the specific PME bit that changes in the root ports? Can you
collect the "sudo lspci -vvxxxx" output with and without ASPM?
The capability bits are generally read-only as far as the PCI spec is
concerned, but devices have implementation-specific knobs that the
BIOS may use to change things. Without CONFIG_PCIEASPM, Linux will
not request control of LTR, and that could cause the BIOS to change
something. You should be able to see the LTR control difference in
the dmesg logging about _OSC.
> W/o the "default y" for ASPM control we also have the situation now
> that the config option description says "When in doubt, say Y."
> but it takes the EXPERT mode to enable it. This seems to be a little
> bit inconsistent.
We should probably remove the "if EXPERT" from the PCIEASPM kconfig.
But I would expect PME to work correctly regardless of PCIEASPM, so
removing "if EXPERT" doesn't solve the underlying problem.
Rafael, does this ring any bells for you? I don't remember a
connection between PME and ASPM, but maybe there is one.
> To cut a long story short:
> At least on some systems this change has unwanted side effects.
^ permalink raw reply
* Re: [PATCH v2 05/14] x86/shstk: Re-layout the stack block for shadow stacks
From: Andrew Cooper @ 2020-05-29 19:21 UTC (permalink / raw)
To: Jan Beulich; +Cc: Xen-devel, Wei Liu, Roger Pau Monné
In-Reply-To: <03cc30f8-4849-f77d-857d-b63248c70a25@suse.com>
On 28/05/2020 13:33, Jan Beulich wrote:
> On 27.05.2020 21:18, Andrew Cooper wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -365,20 +365,15 @@ static void show_guest_stack(struct vcpu *v, const struct cpu_user_regs *regs)
>> /*
>> * Notes for get_stack_trace_bottom() and get_stack_dump_bottom()
>> *
>> - * Stack pages 0 - 3:
>> + * Stack pages 1 - 4:
>> * These are all 1-page IST stacks. Each of these stacks have an exception
>> * frame and saved register state at the top. The interesting bound for a
>> * trace is the word adjacent to this, while the bound for a dump is the
>> * very top, including the exception frame.
>> *
>> - * Stack pages 4 and 5:
>> - * None of these are particularly interesting. With MEMORY_GUARD, page 5 is
>> - * explicitly not present, so attempting to dump or trace it is
>> - * counterproductive. Without MEMORY_GUARD, it is possible for a call chain
>> - * to use the entire primary stack and wander into page 5. In this case,
>> - * consider these pages an extension of the primary stack to aid debugging
>> - * hopefully rare situations where the primary stack has effective been
>> - * overflown.
>> + * Stack pages 0 and 5:
>> + * Shadow stacks. These are mapped read-only, and used by CET-SS capable
>> + * processors. They will never contain regular stack data.
> I don't mind the comment getting put in place already here, but will it
> reflect reality even when CET-SS is not in use, in that the pages then
> still are mapped r/o rather than being left unmapped to act as guard
> pages not only for stack pushes but also for stack pops?
I can't parse this question.
However, I think it is answered by the following patch which does move
things to unilaterally being r/o even in the non-CET-SS case.
> At which point
> the "dump or trace it is counterproductive" remark would still apply in
> this case, and hence may better be retained.
Well - I'm thinking forwards to cleanup where we'd want to integrate the
shadow stack into stack trace reporting, at which point we would
consider these frames interesting to dump/trace.
>
>> @@ -392,13 +387,10 @@ unsigned long get_stack_trace_bottom(unsigned long sp)
>> {
>> switch ( get_stack_page(sp) )
>> {
>> - case 0 ... 3:
>> + case 1 ... 4:
>> return ROUNDUP(sp, PAGE_SIZE) -
>> offsetof(struct cpu_user_regs, es) - sizeof(unsigned long);
>>
>> -#ifndef MEMORY_GUARD
>> - case 4 ... 5:
>> -#endif
>> case 6 ... 7:
>> return ROUNDUP(sp, STACK_SIZE) -
>> sizeof(struct cpu_info) - sizeof(unsigned long);
>> @@ -412,12 +404,9 @@ unsigned long get_stack_dump_bottom(unsigned long sp)
>> {
>> switch ( get_stack_page(sp) )
>> {
>> - case 0 ... 3:
>> + case 1 ... 4:
>> return ROUNDUP(sp, PAGE_SIZE) - sizeof(unsigned long);
>>
>> -#ifndef MEMORY_GUARD
>> - case 4 ... 5:
>> -#endif
>> case 6 ... 7:
>> return ROUNDUP(sp, STACK_SIZE) - sizeof(unsigned long);
> The need to adjust these literal numbers demonstrates how fragile
> this is. I admit I can't see a good way to get rid of the literal
> numbers altogether,
Frankly, this is why there is a massive comment, and I really didn't
want to introduce PRIMARY_SHSTK_SLOT to begin with, because the whole
thing is fragile and there is no obvious naming/labelling scheme which
is liable to survive tweaking.
> but could I talk you into switching to (for
> the latter, as example)
>
> switch ( get_stack_page(sp) )
> {
> case 0: case PRIMARY_SHSTK_SLOT:
> return 0;
>
> case 1 ... 4:
> return ROUNDUP(sp, PAGE_SIZE) - sizeof(unsigned long);
>
> case 6 ... 7:
> return ROUNDUP(sp, STACK_SIZE) - sizeof(unsigned long);
>
> default:
> return sp - sizeof(unsigned long);
> }
>
> ? Of course this will need the callers to be aware they may get
> back zero, but there are only very few (which made me notice the
> functions would better be static).
It was definitely needed externally at some point in the past.
> And the returning of zero may
> then want changing (conditionally upon us using CET-SS) in a
> later patch, where iirc you use the shadow stack for call trace
> generation.
>
> As a positive side effect this will yield a compile error if
> PRIMARY_SHSTK_SLOT gets changed without adjusting these
> functions.
Overall to your question, potentially as future clean-up to how we
express stacks, but not right now for 4.14.
>
>> --- a/xen/include/asm-x86/config.h
>> +++ b/xen/include/asm-x86/config.h
>> @@ -75,6 +75,9 @@
>> /* Primary stack is restricted to 8kB by guard pages. */
>> #define PRIMARY_STACK_SIZE 8192
>>
>> +/* Primary shadow stack is slot 5 of 8, immediately under the primary stack. */
>> +#define PRIMARY_SHSTK_SLOT 5
> Any reason to put it here rather than ...
>
>> --- a/xen/include/asm-x86/current.h
>> +++ b/xen/include/asm-x86/current.h
>> @@ -16,12 +16,12 @@
>> *
>> * 7 - Primary stack (with a struct cpu_info at the top)
>> * 6 - Primary stack
>> - * 5 - Optionally not present (MEMORY_GUARD)
>> - * 4 - Unused; optionally not present (MEMORY_GUARD)
>> - * 3 - Unused; optionally not present (MEMORY_GUARD)
>> - * 2 - MCE IST stack
>> - * 1 - NMI IST stack
>> - * 0 - Double Fault IST stack
>> + * 5 - Primay Shadow Stack (read-only)
>> + * 4 - #DF IST stack
>> + * 3 - #DB IST stack
>> + * 2 - NMI IST stack
>> + * 1 - #MC IST stack
>> + * 0 - IST Shadow Stacks (4x 1k, read-only)
>> */
> ... right below this comment?
Yes - grouping the related constants.
> Same question as above regarding the "read-only" here.
I'll adjust the commit message to make it clearer that some of the text
here is made true in the next patch.
~Andrew
^ permalink raw reply
* Re: [PATCH v2 1/2] spi: dw: Make DMA request line assignments explicit for Intel Medfield
From: Andy Shevchenko @ 2020-05-29 19:21 UTC (permalink / raw)
To: Serge Semin; +Cc: Andy Shevchenko, Serge Semin, Mark Brown, linux-spi
In-Reply-To: <20200529190416.lwou54v6a3suicfd@mobilestation>
On Fri, May 29, 2020 at 10:05 PM Serge Semin <fancer.lancer@gmail.com> wrote:
> On Fri, May 29, 2020 at 09:49:55PM +0300, Andy Shevchenko wrote:
> > On Fri, May 29, 2020 at 09:40:50PM +0300, Serge Semin wrote:
> > > On Fri, May 29, 2020 at 09:31:49PM +0300, Andy Shevchenko wrote:
...
> > > You know my attitude to these changes.) But anyway what's the point in having
> > > the *tx and *rx pointers here? Without any harm to the readability you can use
> > > the structures names directly, don't you?
> >
> > I will wait for Mark to decide.
>
> So no response to a review comment? Shall I do the same when get a review from
> you?.)
This patch is result of you insisting on your version of things when I
tried to explain you that it's not how it should be done. You pushed
your vision. Mark proposed to submit your changes and consider mine
which I agreed on. I will wait for him.
> I am not asking about the whole patch purpose. You know what I think about it.
> My question was about why *tx and *rx pointers are required? Just wondering, I
> may misunderstand something... As I see it you could use dma_tx and dma_rx here
> directly with the same level of readability.
I'll consider this in case v3 will be needed, thanks.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.
From: Dan Williams @ 2020-05-29 19:22 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jan Kara, Michal Suchánek, jack, linuxppc-dev,
Michael Ellerman, linux-nvdimm
In-Reply-To: <7e8ee9e3-4d4d-e4b9-913b-1c2448adc62a@linux.ibm.com>
On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > Hi!
> >
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> >> Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched maintainers for the prctl
> > bits...
> >
> >> On 5/29/20 3:03 PM, Michal Suchánek wrote:
> >>> Adding Jan
> >>>
> >>> On Fri, May 29, 2020 at 11:11:39AM +0530, Aneesh Kumar K.V wrote:
> >>>> With POWER10, architecture is adding new pmem flush and sync instructions.
> >>>> The kernel should prevent the usage of MAP_SYNC if applications are not using
> >>>> the new instructions on newer hardware.
> >>>>
> >>>> This patch adds a prctl option MAP_SYNC_ENABLE that can be used to enable
> >>>> the usage of MAP_SYNC. The kernel config option is added to allow the user
> >>>> to control whether MAP_SYNC should be enabled by default or not.
> >>>>
> >>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > ...
> >>>> diff --git a/kernel/fork.c b/kernel/fork.c
> >>>> index 8c700f881d92..d5a9a363e81e 100644
> >>>> --- a/kernel/fork.c
> >>>> +++ b/kernel/fork.c
> >>>> @@ -963,6 +963,12 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(mmlist_lock);
> >>>> static unsigned long default_dump_filter = MMF_DUMP_FILTER_DEFAULT;
> >>>> +#ifdef CONFIG_ARCH_MAP_SYNC_DISABLE
> >>>> +unsigned long default_map_sync_mask = MMF_DISABLE_MAP_SYNC_MASK;
> >>>> +#else
> >>>> +unsigned long default_map_sync_mask = 0;
> >>>> +#endif
> >>>> +
> >
> > I'm not sure CONFIG is really the right approach here. For a distro that would
> > basically mean to disable MAP_SYNC for all PPC kernels unless application
> > explicitly uses the right prctl. Shouldn't we rather initialize
> > default_map_sync_mask on boot based on whether the CPU we run on requires
> > new flush instructions or not? Otherwise the patch looks sensible.
> >
>
> yes that is correct. We ideally want to deny MAP_SYNC only w.r.t
> POWER10. But on a virtualized platform there is no easy way to detect
> that. We could ideally hook this into the nvdimm driver where we look at
> the new compat string ibm,persistent-memory-v2 and then disable MAP_SYNC
> if we find a device with the specific value.
>
> BTW with the recent changes I posted for the nvdimm driver, older kernel
> won't initialize persistent memory device on newer hardware. Newer
> hardware will present the device to OS with a different device tree
> compat string.
>
> My expectation w.r.t this patch was, Distro would want to mark
> CONFIG_ARCH_MAP_SYNC_DISABLE=n based on the different application
> certification. Otherwise application will have to end up calling the
> prctl(MMF_DISABLE_MAP_SYNC, 0) any way. If that is the case, should this
> be dependent on P10?
>
> With that I am wondering should we even have this patch? Can we expect
> userspace get updated to use new instruction?.
>
> With ppc64 we never had a real persistent memory device available for
> end user to try. The available persistent memory stack was using vPMEM
> which was presented as a volatile memory region for which there is no
> need to use any of the flush instructions. We could safely assume that
> as we get applications certified/verified for working with pmem device
> on ppc64, they would all be using the new instructions?
I think prctl is the wrong interface for this. I was thinking a sysfs
interface along the same lines as /sys/block/pmemX/dax/write_cache.
That attribute is toggling DAXDEV_WRITE_CACHE for the determination of
whether the platform or the kernel needs to handle cache flushing
relative to power loss. A similar attribute can be established for
DAXDEV_SYNC, it would simply default to off based on a configuration
time policy, but be dynamically changeable at runtime via sysfs.
These flags are device properties that affect the kernel and
userspace's handling of persistence.
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
^ permalink raw reply
* Re: robinhood, fanotify name info events and lustre changelog
From: Quentin.BOUGET @ 2020-05-29 18:41 UTC (permalink / raw)
To: Dominique Martinet, Amir Goldstein
Cc: Jan Kara, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org, robinhood-devel@lists.sf.net
In-Reply-To: <20200528125651.GA12279@nautica>
Hi,
Developer of robinhood v4 here,
> > > [1] https://github.com/cea-hpc/robinhood/
The sources for version 4 live in a separate branch:
https://github.com/cea-hpc/robinhood/tree/v4
Any feedback is welcome =)
I am guessing the most interesting bits for this discussion should be found
here:
https://github.com/cea-hpc/robinhood/blob/v4/include/robinhood/fsevent.h
I am not sure it will matter for the rest of the conversation, but just in case:
RobinHood v4 has a notion of a "namespace" xattr (like an xattr, but for
a dentry rather than an inode), it is used it to store things that are only
really tied to the namespace (like the path of an entry). I don't think this
is really relevant here, you can probably ignore it.
Also, RobinHood uses file handles to uniquely identify filesystem entries,
and this is what is stored in a `struct rbh_id`.
> > I couldn't find the documentation for Lustre Changelog format, because
> > the name of the feature is not very Google friendly.
Yes, this is really unfortunate. For the record, user documentation for Lustre
lives at: http://doc.lustre.org/lustre_manual.xhtml
Chapter 12.1 deals with "Lustre Changelogs" (not much more there than
what Dominique already wrote).
> > There is one critical difference between a changelog and fanotify events.
> > fanotify events are delivered a-synchronically and may be delivered out
> > of order, so application must not rely on path information to update
> > internal records without using fstatat(2) to check the actual state of the
> > object in the filesystem.
> lustre changelogs are asynchronous but the order is guaranteed so we
> might rely on that for robinhood v4,
Yes, we do. At least to a certain extent : we at least expect changelog records
for a single filesystem entry to be emitted in the order they happened on the
FS. I have not really given much thought to how things would work in general
if that wasn't true, but I know this is an issue for things that deal with the
namespace : https://jira.whamcloud.com/browse/LU-12574
> but full path is not computed from
> information in the changelogs. Instead the design plan is to have a
> process scrub the database for files that got updated since the last
> path update and fix paths with fstatat, so I think it might work ; but
> that unfortunately hasn't been implemented yet.
Not exactly (I am not sure it really matters, so I'll try to be brief).
The idea to keep paths in sync with what's in the filesystem is to "tag"
entries as we update their name (ie. after a rename). Then a separate
process comes in, queries for entries that have that "tag", and updates
their path by concatenating their parent's path (if the parents themselves
are not "tagged") with the entries' own, up-to-date name. After that, if
the entry was a directory, its children are "tagged". I simplified a bit, but
that's the idea.
So, to be fair, full paths _are_ computed solely from information in the
changelog records, even though it requires a bit of processing on the side.
No additional query to the filesystem for that.
Cheers,
Quentin
^ permalink raw reply
* Re: [PATCH 2/2] sev: scan guest ROM for launch secret address
From: Tom Lendacky @ 2020-05-29 19:08 UTC (permalink / raw)
To: Tobin Feldman-Fitzthum, jejb, qemu-devel; +Cc: Brijesh Singh, tobin
In-Reply-To: <20200528205114.42078-3-tobin@linux.vnet.ibm.com>
On 5/28/20 3:51 PM, Tobin Feldman-Fitzthum wrote:
> From: Tobin Feldman-Fitzthum <tobin@ibm.com>
>
> In addition to using QMP to provide the guest memory address
> that the launch secret blob will be injected into, the
> secret address can also be specified in the guest ROM. This
> patch adds sev_find_secret_gpa, which scans the ROM page by
> page to find a launch secret table identified by a GUID. If
> the table is found, the address it contains will be used
> in place of any address specified via QMP.
I'm working on something similar for SEV-ES support in OVMF (see
https://www.mail-archive.com/devel@edk2.groups.io/msg20716.html). The GUID
is placed at a fixed location from the end of the ROM. One of the OVMF
maintainers recommended the approach and I think we should work to support
the guest LAUNCH SECRET GPA using the same GUID. This particular patch
should be delayed until an OVMF method is accepted, so that it doesn't
have to be reworked.
Thanks,
Tom
>
> Signed-off-by: Tobin Feldman-Fitzthum <tobin@linux.vnet.ibm.com>
> ---
> target/i386/sev.c | 34 ++++++++++++++++++++++++++++++++--
> target/i386/sev_i386.h | 16 ++++++++++++++++
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 774e47d9d1..4adc56d7e3 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -706,6 +706,8 @@ sev_guest_init(const char *id)
> s->api_major = status.api_major;
> s->api_minor = status.api_minor;
>
> + s->secret_gpa = 0;
> +
> trace_kvm_sev_init();
> ret = sev_ioctl(s->sev_fd, KVM_SEV_INIT, NULL, &fw_error);
> if (ret) {
> @@ -731,6 +733,28 @@ err:
> return NULL;
> }
>
> +static void
> +sev_find_secret_gpa(uint8_t *ptr, uint64_t len)
> +{
> + uint64_t offset;
> +
> + SevROMSecretTable *secret_table;
> + QemuUUID secret_table_guid;
> +
> + qemu_uuid_parse(SEV_ROM_SECRET_GUID,&secret_table_guid);
> + secret_table_guid = qemu_uuid_bswap(secret_table_guid);
> +
> + offset = len - 0x1000;
> + while(offset > 0) {
> + secret_table = (SevROMSecretTable *)(ptr + offset);
> + if(qemu_uuid_is_equal(&secret_table_guid, (QemuUUID *) secret_table)){
> + sev_state->secret_gpa = (long unsigned int) secret_table->base;
> + break;
> + }
> + offset -= 0x1000;
> + }
> +}
> +
> int
> sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
> {
> @@ -738,6 +762,9 @@ sev_encrypt_data(void *handle, uint8_t *ptr, uint64_t len)
>
> /* if SEV is in update state then encrypt the data else do nothing */
> if (sev_check_state(SEV_STATE_LAUNCH_UPDATE)) {
> + if(!sev_state->secret_gpa) {
> + sev_find_secret_gpa(ptr, len);
> + }
> return sev_launch_update_data(ptr, len);
> }
>
> @@ -776,8 +803,8 @@ int sev_inject_launch_secret(const char *packet_hdr,
>
> /* secret can be inject only in this state */
> if (!sev_check_state(SEV_STATE_LAUNCH_SECRET)) {
> - error_report("Not in correct state. %x",sev_state->state);
> - return 1;
> + error_report("Not in correct state. %x",sev_state->state);
> + return 1;
> }
>
> hdr = g_base64_decode(packet_hdr, &hdr_sz);
> @@ -792,6 +819,9 @@ int sev_inject_launch_secret(const char *packet_hdr,
> goto err;
> }
>
> + if(sev_state->secret_gpa)
> + gpa = sev_state->secret_gpa;
> +
> hva = gpa2hva(gpa, data_sz);
> if (!hva) {
> goto err;
> diff --git a/target/i386/sev_i386.h b/target/i386/sev_i386.h
> index 8ada9d385d..b1f9ab93bb 100644
> --- a/target/i386/sev_i386.h
> +++ b/target/i386/sev_i386.h
> @@ -19,6 +19,7 @@
> #include "sysemu/kvm.h"
> #include "sysemu/sev.h"
> #include "qemu/error-report.h"
> +#include "qemu/uuid.h"
> #include "qapi/qapi-types-misc-target.h"
>
> #define SEV_POLICY_NODBG 0x1
> @@ -28,6 +29,8 @@
> #define SEV_POLICY_DOMAIN 0x10
> #define SEV_POLICY_SEV 0x20
>
> +#define SEV_ROM_SECRET_GUID "adf956ad-e98c-484c-ae11-b51c7d336447"
> +
> #define TYPE_QSEV_GUEST_INFO "sev-guest"
> #define QSEV_GUEST_INFO(obj) \
> OBJECT_CHECK(QSevGuestInfo, (obj), TYPE_QSEV_GUEST_INFO)
> @@ -42,6 +45,18 @@ extern SevCapability *sev_get_capabilities(void);
>
> typedef struct QSevGuestInfo QSevGuestInfo;
> typedef struct QSevGuestInfoClass QSevGuestInfoClass;
> +typedef struct SevROMSecretTable SevROMSecretTable;
> +
> +/**
> + * If guest physical address for the launch secret is
> + * provided in the ROM, it should be in the following
> + * page-aligned structure.
> + */
> +struct SevROMSecretTable {
> + QemuUUID guid;
> + unsigned int base;
> + unsigned int size;
> +};
>
> /**
> * QSevGuestInfo:
> @@ -78,6 +93,7 @@ struct SEVState {
> uint32_t cbitpos;
> uint32_t reduced_phys_bits;
> uint32_t handle;
> + uint64_t secret_gpa;
> int sev_fd;
> SevState state;
> gchar *measurement;
>
^ permalink raw reply
* Re: [PATCH v4 1/4] dt-bindings: dmaengine: Add MediaTek Command-Queue DMA controller bindings
From: Rob Herring @ 2020-05-29 19:24 UTC (permalink / raw)
To: EastL
Cc: Sean Wang, vkoul, mark.rutland, matthias.bgg, dmaengine,
linux-kernel, linux-arm-kernel, linux-mediatek, devicetree,
wsd_upstream
In-Reply-To: <1590659832-31476-2-git-send-email-EastL.Lee@mediatek.com>
On Thu, May 28, 2020 at 05:57:09PM +0800, EastL wrote:
> Document the devicetree bindings for MediaTek Command-Queue DMA controller
> which could be found on MT6779 SoC or other similar Mediatek SoCs.
>
> Signed-off-by: EastL <EastL.Lee@mediatek.com>
Need a full name.
> ---
> .../devicetree/bindings/dma/mtk-cqdma.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
>
> diff --git a/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> new file mode 100644
> index 0000000..045aa0c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mtk-cqdma.yaml
> @@ -0,0 +1,100 @@
> +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/dma/mtk-cqdma.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek Command-Queue DMA controller Device Tree Binding
> +
> +maintainers:
> + - EastL <EastL.Lee@mediatek.com>
> +
> +description:
> + MediaTek Command-Queue DMA controller (CQDMA) on Mediatek SoC
> + is dedicated to memory-to-memory transfer through queue based
> + descriptor management.
> +
Need a $ref to dma-controller.yaml
> +properties:
> + "#dma-cells":
> + minimum: 1
> + # Should be enough
> + maximum: 255
> + description:
> + Used to provide DMA controller specific information.
> +
> + compatible:
> + const: mediatek,cqdma
Needs SoC specific compatible string(s).
> +
> + reg:
> + minItems: 1
> + maxItems: 255
You can have 255 register regions?
You need to define what each region is if more than 1.
> +
> + interrupts:
> + minItems: 1
> + maxItems: 255
255 interrupts?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + const: cqdma
> +
> + dma-channel-mask:
> + description:
> + Bitmask of available DMA channels in ascending order that are
> + not reserved by firmware and are available to the
> + kernel. i.e. first channel corresponds to LSB.
> + The first item in the array is for channels 0-31, the second is for
> + channels 32-63, etc.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + items:
> + minItems: 1
> + # Should be enough
> + maxItems: 255
This already has a definition in dma-common.yaml. Don't copy-n-paste
it. Just add any constraints you have. Like what is the max number of
channels?
> +
> + dma-channels:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA channels supported by the controller.
> +
> + dma-requests:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description:
> + Number of DMA request signals supported by the controller.
Same comment on these 2.
> +
> +required:
> + - "#dma-cells"
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - dma-channel-mask
> + - dma-channels
> + - dma-requests
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/mt6779-clk.h>
> + cqdma: dma-controller@10212000 {
> + compatible = "mediatek,cqdma";
> + reg = <0 0x10212000 0 0x80>,
> + <0 0x10212080 0 0x80>,
> + <0 0x10212100 0 0x80>;
Examples default to 1 cell each for address and size.
> + interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 140 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg_ao CLK_INFRA_CQ_DMA>;
> + clock-names = "cqdma";
> + dma-channel-mask = <63>;
> + dma-channels = <3>;
> + dma-requests = <32>;
> + #dma-cells = <1>;
> + };
> +
> +...
> --
> 1.9.1
^ permalink raw reply
* Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.
From: Dan Williams @ 2020-05-29 19:22 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jan Kara, linux-nvdimm, jack, Jeff Moyer, Oliver O'Halloran,
Michal Suchánek, linuxppc-dev
In-Reply-To: <7e8ee9e3-4d4d-e4b9-913b-1c2448adc62a@linux.ibm.com>
On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> On 5/29/20 3:22 PM, Jan Kara wrote:
> > Hi!
> >
> > On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> >> Thanks Michal. I also missed Jeff in this email thread.
> >
> > And I think you'll also need some of the sched maintainers for the prctl
> > bits...
> >
> >> On 5/29/20 3:03 PM, Michal Suchánek wrote:
> >>> Adding Jan
> >>>
> >>> On Fri, May 29, 2020 at 11:11:39AM +0530, Aneesh Kumar K.V wrote:
> >>>> With POWER10, architecture is adding new pmem flush and sync instructions.
> >>>> The kernel should prevent the usage of MAP_SYNC if applications are not using
> >>>> the new instructions on newer hardware.
> >>>>
> >>>> This patch adds a prctl option MAP_SYNC_ENABLE that can be used to enable
> >>>> the usage of MAP_SYNC. The kernel config option is added to allow the user
> >>>> to control whether MAP_SYNC should be enabled by default or not.
> >>>>
> >>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > ...
> >>>> diff --git a/kernel/fork.c b/kernel/fork.c
> >>>> index 8c700f881d92..d5a9a363e81e 100644
> >>>> --- a/kernel/fork.c
> >>>> +++ b/kernel/fork.c
> >>>> @@ -963,6 +963,12 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(mmlist_lock);
> >>>> static unsigned long default_dump_filter = MMF_DUMP_FILTER_DEFAULT;
> >>>> +#ifdef CONFIG_ARCH_MAP_SYNC_DISABLE
> >>>> +unsigned long default_map_sync_mask = MMF_DISABLE_MAP_SYNC_MASK;
> >>>> +#else
> >>>> +unsigned long default_map_sync_mask = 0;
> >>>> +#endif
> >>>> +
> >
> > I'm not sure CONFIG is really the right approach here. For a distro that would
> > basically mean to disable MAP_SYNC for all PPC kernels unless application
> > explicitly uses the right prctl. Shouldn't we rather initialize
> > default_map_sync_mask on boot based on whether the CPU we run on requires
> > new flush instructions or not? Otherwise the patch looks sensible.
> >
>
> yes that is correct. We ideally want to deny MAP_SYNC only w.r.t
> POWER10. But on a virtualized platform there is no easy way to detect
> that. We could ideally hook this into the nvdimm driver where we look at
> the new compat string ibm,persistent-memory-v2 and then disable MAP_SYNC
> if we find a device with the specific value.
>
> BTW with the recent changes I posted for the nvdimm driver, older kernel
> won't initialize persistent memory device on newer hardware. Newer
> hardware will present the device to OS with a different device tree
> compat string.
>
> My expectation w.r.t this patch was, Distro would want to mark
> CONFIG_ARCH_MAP_SYNC_DISABLE=n based on the different application
> certification. Otherwise application will have to end up calling the
> prctl(MMF_DISABLE_MAP_SYNC, 0) any way. If that is the case, should this
> be dependent on P10?
>
> With that I am wondering should we even have this patch? Can we expect
> userspace get updated to use new instruction?.
>
> With ppc64 we never had a real persistent memory device available for
> end user to try. The available persistent memory stack was using vPMEM
> which was presented as a volatile memory region for which there is no
> need to use any of the flush instructions. We could safely assume that
> as we get applications certified/verified for working with pmem device
> on ppc64, they would all be using the new instructions?
I think prctl is the wrong interface for this. I was thinking a sysfs
interface along the same lines as /sys/block/pmemX/dax/write_cache.
That attribute is toggling DAXDEV_WRITE_CACHE for the determination of
whether the platform or the kernel needs to handle cache flushing
relative to power loss. A similar attribute can be established for
DAXDEV_SYNC, it would simply default to off based on a configuration
time policy, but be dynamically changeable at runtime via sysfs.
These flags are device properties that affect the kernel and
userspace's handling of persistence.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.