This is a followup from [2].
I recently realised that the gpiolib play ugly tricks on the
unsuspecting irq_chip structures by patching the callbacks.
Not only this breaks when an irq_chip structure is made const (which
really should be the default case), but it also forces this structure
to be copied at nauseam for each instance of the GPIO block, which is
a waste of memory.
My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
which does what it says on the tin: don't you dare writing to them.
Gpiolib is further updated not to install its own callbacks, and it
becomes the responsibility of the driver to call into the gpiolib when
required. This is similar to what we do for other subsystems such as
PCI-MSI.
5 drivers are updated to this new model: M1, QC, Tegra, pl061 and AMD
(as I actively use them) keeping a single irq_chip structure, marking
it const, and exposing the new flag.
Nothing breaks, the volume of change is small, the memory usage goes
down and we have fewer callbacks that can be used as attack vectors.
What's not to love?
Since there wasn't any objection in the previous round of review, I'm
going to take this series into -next to see if anything breaks at
scale.
Thanks,
M.
* From v2 [2]:
- Fixed documentation
- Collected RBs, with thanks
* From v1 [1]:
- pl061 and AMD drivers converted
- New helpers to keep the changes small
- New warning for non-converted drivers
- Documentation and TODO updates
[1] https://lore.kernel.org/r/[email protected]
[2] https://lore.kernel.org/r/[email protected]
Marc Zyngier (10):
gpio: Don't fiddle with irqchips marked as immutable
gpio: Expose the gpiochip_irq_re[ql]res helpers
gpio: Add helpers to ease the transition towards immutable irq_chip
gpio: tegra186: Make the irqchip immutable
gpio: pl061: Make the irqchip immutable
pinctrl: apple-gpio: Make the irqchip immutable
pinctrl: msmgpio: Make the irqchip immutable
pinctrl: amd: Make the irqchip immutable
gpio: Update TODO to mention immutable irq_chip structures
Documentation: Update the recommended pattern for GPIO irqchips
Documentation/driver-api/gpio/driver.rst | 175 ++++++++++++++++++-----
drivers/gpio/TODO | 19 +++
drivers/gpio/gpio-pl061.c | 32 +++--
drivers/gpio/gpio-tegra186.c | 32 +++--
drivers/gpio/gpiolib.c | 13 +-
drivers/pinctrl/pinctrl-amd.c | 11 +-
drivers/pinctrl/pinctrl-apple-gpio.c | 29 ++--
drivers/pinctrl/qcom/pinctrl-msm.c | 53 ++++---
include/linux/gpio/driver.h | 16 +++
include/linux/irq.h | 2 +
kernel/irq/debugfs.c | 1 +
11 files changed, 293 insertions(+), 90 deletions(-)
--
2.34.1
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/gpio/gpio-pl061.c | 32 +++++++++++++++++++++++---------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 4ecab700f23f..6464056cb6ae 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -52,7 +52,6 @@ struct pl061 {
void __iomem *base;
struct gpio_chip gc;
- struct irq_chip irq_chip;
int parent_irq;
#ifdef CONFIG_PM
@@ -241,6 +240,8 @@ static void pl061_irq_mask(struct irq_data *d)
gpioie = readb(pl061->base + GPIOIE) & ~mask;
writeb(gpioie, pl061->base + GPIOIE);
raw_spin_unlock(&pl061->lock);
+
+ gpiochip_disable_irq(gc, d->hwirq);
}
static void pl061_irq_unmask(struct irq_data *d)
@@ -250,6 +251,8 @@ static void pl061_irq_unmask(struct irq_data *d)
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
+ gpiochip_enable_irq(gc, d->hwirq);
+
raw_spin_lock(&pl061->lock);
gpioie = readb(pl061->base + GPIOIE) | mask;
writeb(gpioie, pl061->base + GPIOIE);
@@ -283,6 +286,24 @@ static int pl061_irq_set_wake(struct irq_data *d, unsigned int state)
return irq_set_irq_wake(pl061->parent_irq, state);
}
+static void pl061_irq_print_chip(struct irq_data *data, struct seq_file *p)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+
+ seq_printf(p, dev_name(gc->parent));
+}
+
+static const struct irq_chip pl061_irq_chip = {
+ .irq_ack = pl061_irq_ack,
+ .irq_mask = pl061_irq_mask,
+ .irq_unmask = pl061_irq_unmask,
+ .irq_set_type = pl061_irq_type,
+ .irq_set_wake = pl061_irq_set_wake,
+ .irq_print_chip = pl061_irq_print_chip,
+ .flags = IRQCHIP_IMMUTABLE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = &adev->dev;
@@ -315,13 +336,6 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
/*
* irq_chip support
*/
- pl061->irq_chip.name = dev_name(dev);
- pl061->irq_chip.irq_ack = pl061_irq_ack;
- pl061->irq_chip.irq_mask = pl061_irq_mask;
- pl061->irq_chip.irq_unmask = pl061_irq_unmask;
- pl061->irq_chip.irq_set_type = pl061_irq_type;
- pl061->irq_chip.irq_set_wake = pl061_irq_set_wake;
-
writeb(0, pl061->base + GPIOIE); /* disable irqs */
irq = adev->irq[0];
if (!irq)
@@ -329,7 +343,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
pl061->parent_irq = irq;
girq = &pl061->gc.irq;
- girq->chip = &pl061->irq_chip;
+ gpio_irq_chip_set_chip(girq, &pl061_irq_chip);
girq->parent_handler = pl061_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
--
2.34.1
Update the documentation to get rid of the per-gpio_irq_chip
irq_chip structure, and give examples of the new pattern.
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
---
Documentation/driver-api/gpio/driver.rst | 175 ++++++++++++++++++-----
1 file changed, 142 insertions(+), 33 deletions(-)
diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst
index bbc53920d4dd..a1ddefa1f55f 100644
--- a/Documentation/driver-api/gpio/driver.rst
+++ b/Documentation/driver-api/gpio/driver.rst
@@ -417,30 +417,66 @@ struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip.
If you do this, the additional irq_chip will be set up by gpiolib at the
same time as setting up the rest of the GPIO functionality. The following
is a typical example of a chained cascaded interrupt handler using
-the gpio_irq_chip:
+the gpio_irq_chip. Note how the mask/unmask (or disable/enable) functions
+call into the core gpiolib code:
.. code-block:: c
- /* Typical state container with dynamic irqchip */
+ /* Typical state container */
struct my_gpio {
struct gpio_chip gc;
- struct irq_chip irq;
+ };
+
+ static void my_gpio_mask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ /*
+ * Perform any necessary action to mask the interrupt,
+ * and then call into the core code to synchronise the
+ * state.
+ */
+
+ gpiochip_disable_irq(gc, d->hwirq);
+ }
+
+ static void my_gpio_unmask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ gpiochip_enable_irq(gc, d->hwirq);
+
+ /*
+ * Perform any necessary action to unmask the interrupt,
+ * after having called into the core code to synchronise
+ * the state.
+ */
+ }
+
+ /*
+ * Statically populate the irqchip. Note that it is made const
+ * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
+ * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
+ * callbacks to the structure.
+ */
+ static const struct irq_chip my_gpio_irq_chip = {
+ .name = "my_gpio_irq",
+ .irq_ack = my_gpio_ack_irq,
+ .irq_mask = my_gpio_mask_irq,
+ .irq_unmask = my_gpio_unmask_irq,
+ .irq_set_type = my_gpio_set_irq_type,
+ .flags = IRQCHIP_IMMUTABLE,
+ /* Provide the gpio resource callbacks */
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
};
int irq; /* from platform etc */
struct my_gpio *g;
struct gpio_irq_chip *girq;
- /* Set up the irqchip dynamically */
- g->irq.name = "my_gpio_irq";
- g->irq.irq_ack = my_gpio_ack_irq;
- g->irq.irq_mask = my_gpio_mask_irq;
- g->irq.irq_unmask = my_gpio_unmask_irq;
- g->irq.irq_set_type = my_gpio_set_irq_type;
-
/* Get a pointer to the gpio_irq_chip */
girq = &g->gc.irq;
- girq->chip = &g->irq;
+ gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
girq->parent_handler = ftgpio_gpio_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
@@ -458,23 +494,58 @@ the interrupt separately and go with it:
.. code-block:: c
- /* Typical state container with dynamic irqchip */
+ /* Typical state container */
struct my_gpio {
struct gpio_chip gc;
- struct irq_chip irq;
+ };
+
+ static void my_gpio_mask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ /*
+ * Perform any necessary action to mask the interrupt,
+ * and then call into the core code to synchronise the
+ * state.
+ */
+
+ gpiochip_disable_irq(gc, d->hwirq);
+ }
+
+ static void my_gpio_unmask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ gpiochip_enable_irq(gc, d->hwirq);
+
+ /*
+ * Perform any necessary action to unmask the interrupt,
+ * after having called into the core code to synchronise
+ * the state.
+ */
+ }
+
+ /*
+ * Statically populate the irqchip. Note that it is made const
+ * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
+ * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
+ * callbacks to the structure.
+ */
+ static const struct irq_chip my_gpio_irq_chip = {
+ .name = "my_gpio_irq",
+ .irq_ack = my_gpio_ack_irq,
+ .irq_mask = my_gpio_mask_irq,
+ .irq_unmask = my_gpio_unmask_irq,
+ .irq_set_type = my_gpio_set_irq_type,
+ .flags = IRQCHIP_IMMUTABLE,
+ /* Provide the gpio resource callbacks */
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
};
int irq; /* from platform etc */
struct my_gpio *g;
struct gpio_irq_chip *girq;
- /* Set up the irqchip dynamically */
- g->irq.name = "my_gpio_irq";
- g->irq.irq_ack = my_gpio_ack_irq;
- g->irq.irq_mask = my_gpio_mask_irq;
- g->irq.irq_unmask = my_gpio_unmask_irq;
- g->irq.irq_set_type = my_gpio_set_irq_type;
-
ret = devm_request_threaded_irq(dev, irq, NULL,
irq_thread_fn, IRQF_ONESHOT, "my-chip", g);
if (ret < 0)
@@ -482,7 +553,7 @@ the interrupt separately and go with it:
/* Get a pointer to the gpio_irq_chip */
girq = &g->gc.irq;
- girq->chip = &g->irq;
+ gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
/* This will let us handle the parent IRQ in the driver */
girq->parent_handler = NULL;
girq->num_parents = 0;
@@ -500,24 +571,61 @@ In this case the typical set-up will look like this:
/* Typical state container with dynamic irqchip */
struct my_gpio {
struct gpio_chip gc;
- struct irq_chip irq;
struct fwnode_handle *fwnode;
};
- int irq; /* from platform etc */
+ static void my_gpio_mask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ /*
+ * Perform any necessary action to mask the interrupt,
+ * and then call into the core code to synchronise the
+ * state.
+ */
+
+ gpiochip_disable_irq(gc, d->hwirq);
+ irq_mask_mask_parent(d);
+ }
+
+ static void my_gpio_unmask_irq(struct irq_data *d)
+ {
+ struct gpio_chip *gc = irq_desc_get_handler_data(d);
+
+ gpiochip_enable_irq(gc, d->hwirq);
+
+ /*
+ * Perform any necessary action to unmask the interrupt,
+ * after having called into the core code to synchronise
+ * the state.
+ */
+
+ irq_mask_unmask_parent(d);
+ }
+
+ /*
+ * Statically populate the irqchip. Note that it is made const
+ * (further indicated by the IRQCHIP_IMMUTABLE flag), and that
+ * the GPIOCHIP_IRQ_RESOURCE_HELPER macro adds some extra
+ * callbacks to the structure.
+ */
+ static const struct irq_chip my_gpio_irq_chip = {
+ .name = "my_gpio_irq",
+ .irq_ack = my_gpio_ack_irq,
+ .irq_mask = my_gpio_mask_irq,
+ .irq_unmask = my_gpio_unmask_irq,
+ .irq_set_type = my_gpio_set_irq_type,
+ .flags = IRQCHIP_IMMUTABLE,
+ /* Provide the gpio resource callbacks */
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+ };
+
struct my_gpio *g;
struct gpio_irq_chip *girq;
- /* Set up the irqchip dynamically */
- g->irq.name = "my_gpio_irq";
- g->irq.irq_ack = my_gpio_ack_irq;
- g->irq.irq_mask = my_gpio_mask_irq;
- g->irq.irq_unmask = my_gpio_unmask_irq;
- g->irq.irq_set_type = my_gpio_set_irq_type;
-
/* Get a pointer to the gpio_irq_chip */
girq = &g->gc.irq;
- girq->chip = &g->irq;
+ gpio_irq_chip_set_chip(girq, &my_gpio_irq_chip);
girq->default_type = IRQ_TYPE_NONE;
girq->handler = handle_bad_irq;
girq->fwnode = g->fwnode;
@@ -605,8 +713,9 @@ When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .irq_disable() and .irq_enable() callbacks from the
irqchip.
-When using the gpiolib irqchip helpers, these callbacks are automatically
-assigned.
+When IRQCHIP_IMMUTABLE is not advertised by the irqchip, these callbacks
+are automatically assigned. This behaviour is deprecated and on its way
+to be removed from the kernel.
Real-Time compliance for GPIO IRQ chips
--
2.34.1
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/pinctrl/pinctrl-apple-gpio.c | 29 +++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-apple-gpio.c b/drivers/pinctrl/pinctrl-apple-gpio.c
index 72f4dd2466e1..5e610849dfc3 100644
--- a/drivers/pinctrl/pinctrl-apple-gpio.c
+++ b/drivers/pinctrl/pinctrl-apple-gpio.c
@@ -36,7 +36,6 @@ struct apple_gpio_pinctrl {
struct pinctrl_desc pinctrl_desc;
struct gpio_chip gpio_chip;
- struct irq_chip irq_chip;
u8 irqgrps[];
};
@@ -275,17 +274,21 @@ static unsigned int apple_gpio_irq_type(unsigned int type)
static void apple_gpio_irq_mask(struct irq_data *data)
{
- struct apple_gpio_pinctrl *pctl = gpiochip_get_data(irq_data_get_irq_chip_data(data));
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct apple_gpio_pinctrl *pctl = gpiochip_get_data(gc);
apple_gpio_set_reg(pctl, data->hwirq, REG_GPIOx_MODE,
FIELD_PREP(REG_GPIOx_MODE, REG_GPIOx_IN_IRQ_OFF));
+ gpiochip_disable_irq(gc, data->hwirq);
}
static void apple_gpio_irq_unmask(struct irq_data *data)
{
- struct apple_gpio_pinctrl *pctl = gpiochip_get_data(irq_data_get_irq_chip_data(data));
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+ struct apple_gpio_pinctrl *pctl = gpiochip_get_data(gc);
unsigned int irqtype = apple_gpio_irq_type(irqd_get_trigger_type(data));
+ gpiochip_enable_irq(gc, data->hwirq);
apple_gpio_set_reg(pctl, data->hwirq, REG_GPIOx_MODE,
FIELD_PREP(REG_GPIOx_MODE, irqtype));
}
@@ -343,13 +346,15 @@ static void apple_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(chip, desc);
}
-static struct irq_chip apple_gpio_irqchip = {
- .name = "Apple-GPIO",
- .irq_startup = apple_gpio_irq_startup,
- .irq_ack = apple_gpio_irq_ack,
- .irq_mask = apple_gpio_irq_mask,
- .irq_unmask = apple_gpio_irq_unmask,
- .irq_set_type = apple_gpio_irq_set_type,
+static const struct irq_chip apple_gpio_irqchip = {
+ .name = "Apple-GPIO",
+ .irq_startup = apple_gpio_irq_startup,
+ .irq_ack = apple_gpio_irq_ack,
+ .irq_mask = apple_gpio_irq_mask,
+ .irq_unmask = apple_gpio_irq_unmask,
+ .irq_set_type = apple_gpio_irq_set_type,
+ .flags = IRQCHIP_IMMUTABLE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
};
/* Probe & register */
@@ -360,8 +365,6 @@ static int apple_gpio_register(struct apple_gpio_pinctrl *pctl)
void **irq_data = NULL;
int ret;
- pctl->irq_chip = apple_gpio_irqchip;
-
pctl->gpio_chip.label = dev_name(pctl->dev);
pctl->gpio_chip.request = gpiochip_generic_request;
pctl->gpio_chip.free = gpiochip_generic_free;
@@ -377,7 +380,7 @@ static int apple_gpio_register(struct apple_gpio_pinctrl *pctl)
if (girq->num_parents) {
int i;
- girq->chip = &pctl->irq_chip;
+ gpio_irq_chip_set_chip(girq, &apple_gpio_irqchip);
girq->parent_handler = apple_gpio_irq_handler;
girq->parents = kmalloc_array(girq->num_parents,
--
2.34.1
The following commit has been merged into the irq/irqchip-next branch of irqchip:
Commit-ID: 15d8c14ac849f41f2d41dbddb69f402aaf73ff8b
Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/15d8c14ac849f41f2d41dbddb69f402aaf73ff8b
Author: Marc Zyngier <[email protected]>
AuthorDate: Tue, 19 Apr 2022 15:18:41 +01:00
Committer: Marc Zyngier <[email protected]>
CommitterDate: Tue, 19 Apr 2022 15:22:26 +01:00
gpio: pl061: Make the irqchip immutable
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
drivers/gpio/gpio-pl061.c | 32 +++++++++++++++++++++++---------
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 4ecab70..6464056 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -52,7 +52,6 @@ struct pl061 {
void __iomem *base;
struct gpio_chip gc;
- struct irq_chip irq_chip;
int parent_irq;
#ifdef CONFIG_PM
@@ -241,6 +240,8 @@ static void pl061_irq_mask(struct irq_data *d)
gpioie = readb(pl061->base + GPIOIE) & ~mask;
writeb(gpioie, pl061->base + GPIOIE);
raw_spin_unlock(&pl061->lock);
+
+ gpiochip_disable_irq(gc, d->hwirq);
}
static void pl061_irq_unmask(struct irq_data *d)
@@ -250,6 +251,8 @@ static void pl061_irq_unmask(struct irq_data *d)
u8 mask = BIT(irqd_to_hwirq(d) % PL061_GPIO_NR);
u8 gpioie;
+ gpiochip_enable_irq(gc, d->hwirq);
+
raw_spin_lock(&pl061->lock);
gpioie = readb(pl061->base + GPIOIE) | mask;
writeb(gpioie, pl061->base + GPIOIE);
@@ -283,6 +286,24 @@ static int pl061_irq_set_wake(struct irq_data *d, unsigned int state)
return irq_set_irq_wake(pl061->parent_irq, state);
}
+static void pl061_irq_print_chip(struct irq_data *data, struct seq_file *p)
+{
+ struct gpio_chip *gc = irq_data_get_irq_chip_data(data);
+
+ seq_printf(p, dev_name(gc->parent));
+}
+
+static const struct irq_chip pl061_irq_chip = {
+ .irq_ack = pl061_irq_ack,
+ .irq_mask = pl061_irq_mask,
+ .irq_unmask = pl061_irq_unmask,
+ .irq_set_type = pl061_irq_type,
+ .irq_set_wake = pl061_irq_set_wake,
+ .irq_print_chip = pl061_irq_print_chip,
+ .flags = IRQCHIP_IMMUTABLE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
+};
+
static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
{
struct device *dev = &adev->dev;
@@ -315,13 +336,6 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
/*
* irq_chip support
*/
- pl061->irq_chip.name = dev_name(dev);
- pl061->irq_chip.irq_ack = pl061_irq_ack;
- pl061->irq_chip.irq_mask = pl061_irq_mask;
- pl061->irq_chip.irq_unmask = pl061_irq_unmask;
- pl061->irq_chip.irq_set_type = pl061_irq_type;
- pl061->irq_chip.irq_set_wake = pl061_irq_set_wake;
-
writeb(0, pl061->base + GPIOIE); /* disable irqs */
irq = adev->irq[0];
if (!irq)
@@ -329,7 +343,7 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
pl061->parent_irq = irq;
girq = &pl061->gc.irq;
- girq->chip = &pl061->irq_chip;
+ gpio_irq_chip_set_chip(girq, &pl061_irq_chip);
girq->parent_handler = pl061_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
Prevent gpiolib from messing with the irqchip by advertising
the irq_chip structure as immutable, making it const, and adding
the various calls that gpiolib relies upon.
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/pinctrl/pinctrl-amd.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index 1a7d686494ff..0645c2c24f50 100644
--- a/drivers/pinctrl/pinctrl-amd.c
+++ b/drivers/pinctrl/pinctrl-amd.c
@@ -387,6 +387,8 @@ static void amd_gpio_irq_enable(struct irq_data *d)
struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
struct amd_gpio *gpio_dev = gpiochip_get_data(gc);
+ gpiochip_enable_irq(gc, d->hwirq);
+
raw_spin_lock_irqsave(&gpio_dev->lock, flags);
pin_reg = readl(gpio_dev->base + (d->hwirq)*4);
pin_reg |= BIT(INTERRUPT_ENABLE_OFF);
@@ -408,6 +410,8 @@ static void amd_gpio_irq_disable(struct irq_data *d)
pin_reg &= ~BIT(INTERRUPT_MASK_OFF);
writel(pin_reg, gpio_dev->base + (d->hwirq)*4);
raw_spin_unlock_irqrestore(&gpio_dev->lock, flags);
+
+ gpiochip_disable_irq(gc, d->hwirq);
}
static void amd_gpio_irq_mask(struct irq_data *d)
@@ -577,7 +581,7 @@ static void amd_irq_ack(struct irq_data *d)
*/
}
-static struct irq_chip amd_gpio_irqchip = {
+static const struct irq_chip amd_gpio_irqchip = {
.name = "amd_gpio",
.irq_ack = amd_irq_ack,
.irq_enable = amd_gpio_irq_enable,
@@ -593,7 +597,8 @@ static struct irq_chip amd_gpio_irqchip = {
* the wake event. Otherwise the wake event will never clear and
* prevent the system from suspending.
*/
- .flags = IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND,
+ .flags = IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND | IRQCHIP_IMMUTABLE,
+ GPIOCHIP_IRQ_RESOURCE_HELPERS,
};
#define PIN_IRQ_PENDING (BIT(INTERRUPT_STS_OFF) | BIT(WAKE_STS_OFF))
@@ -1026,7 +1031,7 @@ static int amd_gpio_probe(struct platform_device *pdev)
amd_gpio_irq_init(gpio_dev);
girq = &gpio_dev->gc.irq;
- girq->chip = &amd_gpio_irqchip;
+ gpio_irq_chip_set_chip(girq, &amd_gpio_irqchip);
/* This will let us handle the parent IRQ in the driver */
girq->parent_handler = NULL;
girq->num_parents = 0;
--
2.34.1
In order to move away from gpiolib messing with the internals of
unsuspecting irqchips, add a flag by which irqchips advertise
that they are not to be messed with, and do solemnly swear that
they correctly call into the gpiolib helpers when required.
Also nudge the users into converting their drivers to the
new model.
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
---
drivers/gpio/gpiolib.c | 7 ++++++-
include/linux/irq.h | 2 ++
kernel/irq/debugfs.c | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e59884cc12a7..48191e62a3cc 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1475,6 +1475,11 @@ static void gpiochip_set_irq_hooks(struct gpio_chip *gc)
{
struct irq_chip *irqchip = gc->irq.chip;
+ if (irqchip->flags & IRQCHIP_IMMUTABLE)
+ return;
+
+ chip_warn(gc, "not an immutable chip, please consider fixing it!\n");
+
if (!irqchip->irq_request_resources &&
!irqchip->irq_release_resources) {
irqchip->irq_request_resources = gpiochip_irq_reqres;
@@ -1633,7 +1638,7 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gc)
irq_domain_remove(gc->irq.domain);
}
- if (irqchip) {
+ if (irqchip && !(irqchip->flags & IRQCHIP_IMMUTABLE)) {
if (irqchip->irq_request_resources == gpiochip_irq_reqres) {
irqchip->irq_request_resources = NULL;
irqchip->irq_release_resources = NULL;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index f92788ccdba2..505308253d23 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -569,6 +569,7 @@ struct irq_chip {
* IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND: Invokes __enable_irq()/__disable_irq() for wake irqs
* in the suspend path if they are in disabled state
* IRQCHIP_AFFINITY_PRE_STARTUP: Default affinity update before startup
+ * IRQCHIP_IMMUTABLE: Don't ever change anything in this chip
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
@@ -582,6 +583,7 @@ enum {
IRQCHIP_SUPPORTS_NMI = (1 << 8),
IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND = (1 << 9),
IRQCHIP_AFFINITY_PRE_STARTUP = (1 << 10),
+ IRQCHIP_IMMUTABLE = (1 << 11),
};
#include <linux/irqdesc.h>
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index 2b43f5f5033d..bc8e40cf2b65 100644
--- a/kernel/irq/debugfs.c
+++ b/kernel/irq/debugfs.c
@@ -58,6 +58,7 @@ static const struct irq_bit_descr irqchip_flags[] = {
BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
BIT_MASK_DESCR(IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND),
+ BIT_MASK_DESCR(IRQCHIP_IMMUTABLE),
};
static void
--
2.34.1
The following commit has been merged into the irq/irqchip-next branch of irqchip:
Commit-ID: 6c846d026d490b2383d395bc8e7b06336219667b
Gitweb: https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms/6c846d026d490b2383d395bc8e7b06336219667b
Author: Marc Zyngier <[email protected]>
AuthorDate: Tue, 19 Apr 2022 15:18:37 +01:00
Committer: Marc Zyngier <[email protected]>
CommitterDate: Tue, 19 Apr 2022 15:22:25 +01:00
gpio: Don't fiddle with irqchips marked as immutable
In order to move away from gpiolib messing with the internals of
unsuspecting irqchips, add a flag by which irqchips advertise
that they are not to be messed with, and do solemnly swear that
they correctly call into the gpiolib helpers when required.
Also nudge the users into converting their drivers to the
new model.
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
---
drivers/gpio/gpiolib.c | 7 ++++++-
include/linux/irq.h | 2 ++
kernel/irq/debugfs.c | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index e59884c..48191e6 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1475,6 +1475,11 @@ static void gpiochip_set_irq_hooks(struct gpio_chip *gc)
{
struct irq_chip *irqchip = gc->irq.chip;
+ if (irqchip->flags & IRQCHIP_IMMUTABLE)
+ return;
+
+ chip_warn(gc, "not an immutable chip, please consider fixing it!\n");
+
if (!irqchip->irq_request_resources &&
!irqchip->irq_release_resources) {
irqchip->irq_request_resources = gpiochip_irq_reqres;
@@ -1633,7 +1638,7 @@ static void gpiochip_irqchip_remove(struct gpio_chip *gc)
irq_domain_remove(gc->irq.domain);
}
- if (irqchip) {
+ if (irqchip && !(irqchip->flags & IRQCHIP_IMMUTABLE)) {
if (irqchip->irq_request_resources == gpiochip_irq_reqres) {
irqchip->irq_request_resources = NULL;
irqchip->irq_release_resources = NULL;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index f92788c..5053082 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -569,6 +569,7 @@ struct irq_chip {
* IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND: Invokes __enable_irq()/__disable_irq() for wake irqs
* in the suspend path if they are in disabled state
* IRQCHIP_AFFINITY_PRE_STARTUP: Default affinity update before startup
+ * IRQCHIP_IMMUTABLE: Don't ever change anything in this chip
*/
enum {
IRQCHIP_SET_TYPE_MASKED = (1 << 0),
@@ -582,6 +583,7 @@ enum {
IRQCHIP_SUPPORTS_NMI = (1 << 8),
IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND = (1 << 9),
IRQCHIP_AFFINITY_PRE_STARTUP = (1 << 10),
+ IRQCHIP_IMMUTABLE = (1 << 11),
};
#include <linux/irqdesc.h>
diff --git a/kernel/irq/debugfs.c b/kernel/irq/debugfs.c
index 2b43f5f..bc8e40c 100644
--- a/kernel/irq/debugfs.c
+++ b/kernel/irq/debugfs.c
@@ -58,6 +58,7 @@ static const struct irq_bit_descr irqchip_flags[] = {
BIT_MASK_DESCR(IRQCHIP_SUPPORTS_LEVEL_MSI),
BIT_MASK_DESCR(IRQCHIP_SUPPORTS_NMI),
BIT_MASK_DESCR(IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND),
+ BIT_MASK_DESCR(IRQCHIP_IMMUTABLE),
};
static void
On Tue, Apr 19, 2022 at 4:19 PM Marc Zyngier <[email protected]> wrote:
> This is a followup from [2].
>
> I recently realised that the gpiolib play ugly tricks on the
> unsuspecting irq_chip structures by patching the callbacks.
>
> Not only this breaks when an irq_chip structure is made const (which
> really should be the default case), but it also forces this structure
> to be copied at nauseam for each instance of the GPIO block, which is
> a waste of memory.
>
> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> which does what it says on the tin: don't you dare writing to them.
> Gpiolib is further updated not to install its own callbacks, and it
> becomes the responsibility of the driver to call into the gpiolib when
> required. This is similar to what we do for other subsystems such as
> PCI-MSI.
>
> 5 drivers are updated to this new model: M1, QC, Tegra, pl061 and AMD
> (as I actively use them) keeping a single irq_chip structure, marking
> it const, and exposing the new flag.
>
> Nothing breaks, the volume of change is small, the memory usage goes
> down and we have fewer callbacks that can be used as attack vectors.
> What's not to love?
>
> Since there wasn't any objection in the previous round of review, I'm
> going to take this series into -next to see if anything breaks at
> scale.
The series:
Acked-by: Linus Walleij <[email protected]>
Bartosz: if you're happy with this can you apply it to an immutable branch
from v5.18-rc1 and merge that into the GPIO for-next and then I can also
pull that into pinctrl?
Yours,
Linus Walleij
On Fri, 22 Apr 2022 22:24:22 +0100,
Linus Walleij <[email protected]> wrote:
>
> On Tue, Apr 19, 2022 at 4:19 PM Marc Zyngier <[email protected]> wrote:
>
> > This is a followup from [2].
> >
> > I recently realised that the gpiolib play ugly tricks on the
> > unsuspecting irq_chip structures by patching the callbacks.
> >
> > Not only this breaks when an irq_chip structure is made const (which
> > really should be the default case), but it also forces this structure
> > to be copied at nauseam for each instance of the GPIO block, which is
> > a waste of memory.
> >
> > My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> > which does what it says on the tin: don't you dare writing to them.
> > Gpiolib is further updated not to install its own callbacks, and it
> > becomes the responsibility of the driver to call into the gpiolib when
> > required. This is similar to what we do for other subsystems such as
> > PCI-MSI.
> >
> > 5 drivers are updated to this new model: M1, QC, Tegra, pl061 and AMD
> > (as I actively use them) keeping a single irq_chip structure, marking
> > it const, and exposing the new flag.
> >
> > Nothing breaks, the volume of change is small, the memory usage goes
> > down and we have fewer callbacks that can be used as attack vectors.
> > What's not to love?
> >
> > Since there wasn't any objection in the previous round of review, I'm
> > going to take this series into -next to see if anything breaks at
> > scale.
>
> The series:
> Acked-by: Linus Walleij <[email protected]>
>
> Bartosz: if you're happy with this can you apply it to an immutable branch
> from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> pull that into pinctrl?
For what it is worth, I've pushed this branch into irqchip-next.
You can pick it up from:
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
but I can also drop it from the irqchip tree.
Just let me know.
M.
--
Without deviation from the norm, progress is not possible.
On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
>
> On Fri, 22 Apr 2022 22:24:22 +0100,
> Linus Walleij <[email protected]> wrote:
> >
> > On Tue, Apr 19, 2022 at 4:19 PM Marc Zyngier <[email protected]> wrote:
> >
> > > This is a followup from [2].
> > >
> > > I recently realised that the gpiolib play ugly tricks on the
> > > unsuspecting irq_chip structures by patching the callbacks.
> > >
> > > Not only this breaks when an irq_chip structure is made const (which
> > > really should be the default case), but it also forces this structure
> > > to be copied at nauseam for each instance of the GPIO block, which is
> > > a waste of memory.
> > >
> > > My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> > > which does what it says on the tin: don't you dare writing to them.
> > > Gpiolib is further updated not to install its own callbacks, and it
> > > becomes the responsibility of the driver to call into the gpiolib when
> > > required. This is similar to what we do for other subsystems such as
> > > PCI-MSI.
> > >
> > > 5 drivers are updated to this new model: M1, QC, Tegra, pl061 and AMD
> > > (as I actively use them) keeping a single irq_chip structure, marking
> > > it const, and exposing the new flag.
> > >
> > > Nothing breaks, the volume of change is small, the memory usage goes
> > > down and we have fewer callbacks that can be used as attack vectors.
> > > What's not to love?
> > >
> > > Since there wasn't any objection in the previous round of review, I'm
> > > going to take this series into -next to see if anything breaks at
> > > scale.
> >
> > The series:
> > Acked-by: Linus Walleij <[email protected]>
> >
> > Bartosz: if you're happy with this can you apply it to an immutable branch
> > from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> > pull that into pinctrl?
>
> For what it is worth, I've pushed this branch into irqchip-next.
>
> You can pick it up from:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
>
> but I can also drop it from the irqchip tree.
>
> Just let me know.
I would prefer it if it goes as is now and every stakeholder can just
pull it. As far as my drivers are concerned I also want to convert
them sooner than later, meaning I want to pull this into my little
tree as well. Bart, Linus, would it be also preferable for you?
--
With Best Regards,
Andy Shevchenko
On Tue, Apr 26, 2022 at 12:25 PM Andy Shevchenko
<[email protected]> wrote:
> On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
> > You can pick it up from:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
> >
> > but I can also drop it from the irqchip tree.
> >
> > Just let me know.
Pulling that looks good to me.
If Bartosz pulls this to the GPIO tree I will also pull it to pin control,
I just want him to decide, because the impact is biggest on GPIO.
> I would prefer it if it goes as is now and every stakeholder can just
> pull it. As far as my drivers are concerned I also want to convert
> them sooner than later, meaning I want to pull this into my little
> tree as well. Bart, Linus, would it be also preferable for you?
I'd say let's all three pull this branch, Bart?
Yours,
Linus Walleij
On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
> > Bartosz: if you're happy with this can you apply it to an immutable branch
> > from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> > pull that into pinctrl?
>
> For what it is worth, I've pushed this branch into irqchip-next.
>
> You can pick it up from:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
Bartosz are you pulling this? Most of the changes are in GPIO.
Patches have started to arrive that go on top of these changes
so would be nice to have it in both GPIO and pin control as a
baseline.
Yours,
Linus Walleij
On Wed, 04 May 2022 22:21:51 +0100,
Linus Walleij <[email protected]> wrote:
>
> On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
>
> > > Bartosz: if you're happy with this can you apply it to an immutable branch
> > > from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> > > pull that into pinctrl?
> >
> > For what it is worth, I've pushed this branch into irqchip-next.
> >
> > You can pick it up from:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
>
> Bartosz are you pulling this? Most of the changes are in GPIO.
> Patches have started to arrive that go on top of these changes
> so would be nice to have it in both GPIO and pin control as a
> baseline.
I'm happy to queue things on top of my series if that helps.
M.
--
Without deviation from the norm, progress is not possible.
On Wed, May 4, 2022 at 11:22 PM Linus Walleij <[email protected]> wrote:
>
> On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
>
> > > Bartosz: if you're happy with this can you apply it to an immutable branch
> > > from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> > > pull that into pinctrl?
> >
> > For what it is worth, I've pushed this branch into irqchip-next.
> >
> > You can pick it up from:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
>
> Bartosz are you pulling this? Most of the changes are in GPIO.
> Patches have started to arrive that go on top of these changes
> so would be nice to have it in both GPIO and pin control as a
> baseline.
>
> Yours,
> Linus Walleij
Yes! Sorry for the delay. Pulling now.
Bart
On Thu, May 5, 2022 at 2:58 PM Bartosz Golaszewski <[email protected]> wrote:
> On Wed, May 4, 2022 at 11:22 PM Linus Walleij <[email protected]> wrote:
> >
> > On Sat, Apr 23, 2022 at 12:30 PM Marc Zyngier <[email protected]> wrote:
> >
> > > > Bartosz: if you're happy with this can you apply it to an immutable branch
> > > > from v5.18-rc1 and merge that into the GPIO for-next and then I can also
> > > > pull that into pinctrl?
> > >
> > > For what it is worth, I've pushed this branch into irqchip-next.
> > >
> > > You can pick it up from:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gpio-immutable
> >
> > Bartosz are you pulling this? Most of the changes are in GPIO.
> > Patches have started to arrive that go on top of these changes
> > so would be nice to have it in both GPIO and pin control as a
> > baseline.
> >
> > Yours,
> > Linus Walleij
>
> Yes! Sorry for the delay. Pulling now.
Excellent, pulled it into pincontrol as well.
Yours,
Linus Walleij
On Thu, 12 May 2022 18:35:55 +0100,
Andy Shevchenko <[email protected]> wrote:
>
> On Thu, May 12, 2022 at 08:08:28PM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> > > This is a followup from [2].
> > >
> > > I recently realised that the gpiolib play ugly tricks on the
> > > unsuspecting irq_chip structures by patching the callbacks.
> > >
> > > Not only this breaks when an irq_chip structure is made const (which
> > > really should be the default case), but it also forces this structure
> > > to be copied at nauseam for each instance of the GPIO block, which is
> > > a waste of memory.
> >
> > Is this brings us to the issue with IRQ chip name?
> >
> > The use case in my mind is the following:
> > 1) we have two or more GPIO chips that supports IRQ;
> > 2) the user registers two IRQs of the same (by number) pin on different chips;
> > 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
> >
> > So, do I understand correct current state of affairs?
> >
> > If so, we have to fix this to have any kind of ID added to the chip name that
> > we can map /proc/interrupts output correctly.
>
> Hmm... Some drivers are using static names, some -- dynamically
> prepared (one way or another). Either way I think the ID is good to
> have if we still miss it.
No, this is a terrible idea. /proc/interrupts gives you a hint of
which driver/subsystem deals with the interrupt. This isn't a source
of topological information. /sys/kernel/debug/irq has all the
information you can dream of, and much more. Just make use of it.
M.
--
Without deviation from the norm, progress is not possible.
On Thu, May 12, 2022 at 08:08:28PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> > This is a followup from [2].
> >
> > I recently realised that the gpiolib play ugly tricks on the
> > unsuspecting irq_chip structures by patching the callbacks.
> >
> > Not only this breaks when an irq_chip structure is made const (which
> > really should be the default case), but it also forces this structure
> > to be copied at nauseam for each instance of the GPIO block, which is
> > a waste of memory.
>
> Is this brings us to the issue with IRQ chip name?
>
> The use case in my mind is the following:
> 1) we have two or more GPIO chips that supports IRQ;
> 2) the user registers two IRQs of the same (by number) pin on different chips;
> 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
>
> So, do I understand correct current state of affairs?
>
> If so, we have to fix this to have any kind of ID added to the chip name that
> we can map /proc/interrupts output correctly.
Hmm... Some drivers are using static names, some -- dynamically prepared (one
way or another). Either way I think the ID is good to have if we still miss it.
--
With Best Regards,
Andy Shevchenko
On Fri, 13 May 2022 09:43:29 +0100,
Andy Shevchenko <[email protected]> wrote:
>
> On Fri, May 13, 2022 at 12:18 AM Marc Zyngier <[email protected]> wrote:
> > On Thu, 12 May 2022 18:35:55 +0100,
> > Andy Shevchenko <[email protected]> wrote:
> > >
> > > On Thu, May 12, 2022 at 08:08:28PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> > > > > This is a followup from [2].
> > > > >
> > > > > I recently realised that the gpiolib play ugly tricks on the
> > > > > unsuspecting irq_chip structures by patching the callbacks.
> > > > >
> > > > > Not only this breaks when an irq_chip structure is made const (which
> > > > > really should be the default case), but it also forces this structure
> > > > > to be copied at nauseam for each instance of the GPIO block, which is
> > > > > a waste of memory.
> > > >
> > > > Is this brings us to the issue with IRQ chip name?
> > > >
> > > > The use case in my mind is the following:
> > > > 1) we have two or more GPIO chips that supports IRQ;
> > > > 2) the user registers two IRQs of the same (by number) pin on different chips;
> > > > 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
> > > >
> > > > So, do I understand correct current state of affairs?
> > > >
> > > > If so, we have to fix this to have any kind of ID added to the chip name that
> > > > we can map /proc/interrupts output correctly.
> > >
> > > Hmm... Some drivers are using static names, some -- dynamically
> > > prepared (one way or another). Either way I think the ID is good to
> > > have if we still miss it.
> >
> > No, this is a terrible idea. /proc/interrupts gives you a hint of
> > which driver/subsystem deals with the interrupt. This isn't a source
> > of topological information. /sys/kernel/debug/irq has all the
> > information you can dream of, and much more. Just make use of it.
>
> Okay, so IIUC the mapping is that: I got a vIRQ number from
> /proc/interrupts, but then I have to mount debugfs and look into it
> for a detailed answer of which chip/domain this vIRQ belongs to.
Normal users shouldn't care about irqdomains. If you are developing,
you already have debugfs enabled and mounted on your system.
> Also /sys/kernel/irq rings a bell, but not sure if it's related.
This is the same thing as /proc/interrupt, just dumped with a
different format.
M.
--
Without deviation from the norm, progress is not possible.
On Thu, 12 May 2022 18:08:28 +0100,
Andy Shevchenko <[email protected]> wrote:
>
> On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> > This is a followup from [2].
> >
> > I recently realised that the gpiolib play ugly tricks on the
> > unsuspecting irq_chip structures by patching the callbacks.
> >
> > Not only this breaks when an irq_chip structure is made const (which
> > really should be the default case), but it also forces this structure
> > to be copied at nauseam for each instance of the GPIO block, which is
> > a waste of memory.
>
> Is this brings us to the issue with IRQ chip name?
>
> The use case in my mind is the following:
> 1) we have two or more GPIO chips that supports IRQ;
> 2) the user registers two IRQs of the same (by number) pin on different chips;
> 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
/proc/interrupts isn't a dumping ground for debug information. Yes,
some irqchips do that, and they have been fixed by providing the
irq_print_chip callback, thus ensuring that the irq_chip structure is
never written to. I would have loved to simply get rid of the variable
string, but this is obviously ABI, and we can't break that.
> So, do I understand correct current state of affairs?
>
> If so, we have to fix this to have any kind of ID added to the chip name that
> we can map /proc/interrupts output correctly.
This is already done.
That's not an excuse to add more of those though. We already have the
required infrastructure in debugfs, and that's where this sort of
thing should happen.
M.
--
Without deviation from the norm, progress is not possible.
On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> This is a followup from [2].
>
> I recently realised that the gpiolib play ugly tricks on the
> unsuspecting irq_chip structures by patching the callbacks.
>
> Not only this breaks when an irq_chip structure is made const (which
> really should be the default case), but it also forces this structure
> to be copied at nauseam for each instance of the GPIO block, which is
> a waste of memory.
Is this brings us to the issue with IRQ chip name?
The use case in my mind is the following:
1) we have two or more GPIO chips that supports IRQ;
2) the user registers two IRQs of the same (by number) pin on different chips;
3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
So, do I understand correct current state of affairs?
If so, we have to fix this to have any kind of ID added to the chip name that
we can map /proc/interrupts output correctly.
> My current approach is to add a new irq_chip flag (IRQCHIP_IMMUTABLE)
> which does what it says on the tin: don't you dare writing to them.
> Gpiolib is further updated not to install its own callbacks, and it
> becomes the responsibility of the driver to call into the gpiolib when
> required. This is similar to what we do for other subsystems such as
> PCI-MSI.
>
> 5 drivers are updated to this new model: M1, QC, Tegra, pl061 and AMD
> (as I actively use them) keeping a single irq_chip structure, marking
> it const, and exposing the new flag.
>
> Nothing breaks, the volume of change is small, the memory usage goes
> down and we have fewer callbacks that can be used as attack vectors.
> What's not to love?
>
> Since there wasn't any objection in the previous round of review, I'm
> going to take this series into -next to see if anything breaks at
> scale.
--
With Best Regards,
Andy Shevchenko
On Fri, May 13, 2022 at 12:18 AM Marc Zyngier <[email protected]> wrote:
> On Thu, 12 May 2022 18:35:55 +0100,
> Andy Shevchenko <[email protected]> wrote:
> >
> > On Thu, May 12, 2022 at 08:08:28PM +0300, Andy Shevchenko wrote:
> > > On Tue, Apr 19, 2022 at 03:18:36PM +0100, Marc Zyngier wrote:
> > > > This is a followup from [2].
> > > >
> > > > I recently realised that the gpiolib play ugly tricks on the
> > > > unsuspecting irq_chip structures by patching the callbacks.
> > > >
> > > > Not only this breaks when an irq_chip structure is made const (which
> > > > really should be the default case), but it also forces this structure
> > > > to be copied at nauseam for each instance of the GPIO block, which is
> > > > a waste of memory.
> > >
> > > Is this brings us to the issue with IRQ chip name?
> > >
> > > The use case in my mind is the following:
> > > 1) we have two or more GPIO chips that supports IRQ;
> > > 2) the user registers two IRQs of the same (by number) pin on different chips;
> > > 3) cat /proc/interrupt will show 'my_gpio_chip XX', where XX is the number.
> > >
> > > So, do I understand correct current state of affairs?
> > >
> > > If so, we have to fix this to have any kind of ID added to the chip name that
> > > we can map /proc/interrupts output correctly.
> >
> > Hmm... Some drivers are using static names, some -- dynamically
> > prepared (one way or another). Either way I think the ID is good to
> > have if we still miss it.
>
> No, this is a terrible idea. /proc/interrupts gives you a hint of
> which driver/subsystem deals with the interrupt. This isn't a source
> of topological information. /sys/kernel/debug/irq has all the
> information you can dream of, and much more. Just make use of it.
Okay, so IIUC the mapping is that: I got a vIRQ number from
/proc/interrupts, but then I have to mount debugfs and look into it
for a detailed answer of which chip/domain this vIRQ belongs to. Also
/sys/kernel/irq rings a bell, but not sure if it's related.
--
With Best Regards,
Andy Shevchenko