lkml.org 
[lkml]   [2023]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v4 1/2] gpio: gpio-mlxbf3: Add gpio driver support
    On Fri, Feb 17, 2023 at 11:27 PM Asmaa Mnebhi <asmaa@nvidia.com> wrote:
    >
    > Add support for the BlueField-3 SoC GPIO driver.
    > This driver configures and handles GPIO interrupts. It also enables a user
    > to manipulate certain GPIO pins via libgpiod tools or other kernel drivers.
    > The usables pins are defined via the gpio-reserved-ranges property.

    Probably

    "gpio-reserved-ranges"

    (in double quotes).

    ...

    > + depends on (MELLANOX_PLATFORM && ARM64 && ACPI) || (64BIT && COMPILE_TEST)

    But do you really need the ACPI dependency? I don't see a single bit
    of it in the driver.
    (Yes, I know about IDs.)

    Also, how 64BIT is needed for testing?

    ...

    > +#include <linux/version.h>

    I believe it's included automatically. Please, double check the header
    inclusions to make sure you don't have some spurious ones in the list.

    > +struct mlxbf3_gpio_context {
    > + struct gpio_chip gc;
    > +
    > + /* YU GPIO block address */
    > + void __iomem *gpio_io;
    > +
    > + /* YU GPIO cause block address */
    > + void __iomem *gpio_cause_io;
    > +};

    ...

    > + int offset = irqd_to_hwirq(irqd);

    It returns irq_hw_number_t IIRC. It's an unsigned type. Otherwise you
    may have interesting effects.

    ...

    > + int offset = irqd_to_hwirq(irqd);

    Ditto.

    ...

    > + raw_spin_lock_irqsave(&gs->gc.bgpio_lock, flags);
    > +
    > + switch (type & IRQ_TYPE_SENSE_MASK) {
    > + case IRQ_TYPE_EDGE_BOTH:
    > + val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
    > + val |= BIT(offset);
    > + writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
    > + val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
    > + val |= BIT(offset);
    > + writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
    > + break;
    > + case IRQ_TYPE_EDGE_RISING:
    > + val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
    > + val |= BIT(offset);
    > + writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_RISE_EN);
    > + break;
    > + case IRQ_TYPE_EDGE_FALLING:
    > + val = readl(gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
    > + val |= BIT(offset);
    > + writel(val, gs->gpio_io + MLXBF_GPIO_CAUSE_FALL_EN);
    > + break;
    > + default:

    Dead lock starts here.

    > + return -EINVAL;
    > + }
    > +
    > + raw_spin_unlock_irqrestore(&gs->gc.bgpio_lock, flags);

    ...

    > + irq_set_handler_locked(irqd, handle_simple_irq);

    Why not using propert handler type (edge)?

    ...

    > +static const struct irq_chip gpio_mlxbf3_irqchip = {
    > + .name = "MLNXBF33",
    > + .irq_set_type = mlxbf3_gpio_irq_set_type,
    > + .irq_enable = mlxbf3_gpio_irq_enable,
    > + .irq_disable = mlxbf3_gpio_irq_disable,
    > +};

    Seems missing two things (dunno if bgpio_init() helps with that):
    - IMMUTABLE flag
    - actual calls to enable and disable IRQs for internal GPIO library usage

    See other drivers how it's done. There are even plenty of patches to
    enable this thing separately.

    ...

    > +static int
    > +mlxbf3_gpio_probe(struct platform_device *pdev)

    Doesn't it perfectly fit one line?

    ...

    > + npins = MLXBF3_GPIO_MAX_PINS_PER_BLOCK;
    > + device_property_read_u32(dev, "npins", &npins);

    I don't see DT bindings for this property (being added in this
    series). Is it already established one?

    ...

    > + girq->default_type = IRQ_TYPE_NONE;

    Assigning handle_bad_irq() is missing.

    --
    With Best Regards,
    Andy Shevchenko

    \
     
     \ /
      Last update: 2023-03-27 00:27    [W:4.674 / U:0.184 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site