lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 17 Feb 2017 14:47:03 -0800
From:   Hoan Tran <hotran@....com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        Jamie Iles <jamie@...ieiles.com>,
        Weike Chen <alvin.chen@...el.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Loc Ho <lho@....com>, Duc Dang <dhdang@....com>
Subject: Re: [PATCH v2] gpio: dwapb: Add support for next generation of X-Gene SoC

Hi Andy,

On Fri, Feb 17, 2017 at 2:23 AM, Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Fri, Feb 17, 2017 at 3:01 AM, Hoan Tran <hotran@....com> wrote:
>> Next generation of X-Gene SoC's GPIO hardware register map is very
>> similar to DW GPIO. It only differs by a few register addresses.
>> This patch modifies DW GPIO driver to accommodate the difference
>> in a few register addresses.
>
>> --- a/drivers/gpio/gpio-dwapb.c
>> +++ b/drivers/gpio/gpio-dwapb.c
>> @@ -55,6 +56,13 @@
>>  #define GPIO_SWPORT_DR_SIZE    (GPIO_SWPORTB_DR - GPIO_SWPORTA_DR)
>>  #define GPIO_SWPORT_DDR_SIZE   (GPIO_SWPORTB_DDR - GPIO_SWPORTA_DDR)
>>
>> +#define GPIO_REG_OFFSET_V2     1
>
> + empty line
>
>> +#define GPIO_INTMASK_V2                0x44
>> +#define GPIO_INTTYPE_LEVEL_V2  0x34
>> +#define GPIO_INT_POLARITY_V2   0x38
>> +#define GPIO_INTSTATUS_V2      0x3c
>> +#define GPIO_PORTA_EOI_V2      0x40
>
>> +       unsigned int            flags;
>
>> +static inline u32 gpio_reg_convert(struct dwapb_gpio *gpio, unsigned int offset)
>> +{
>
>> +       if (!(gpio->flags & GPIO_REG_OFFSET_V2))
>> +               return offset;
>
> I would split this to to functions:
>
> ... u32 gpio_reg_convert(...) {
>  if (gpio->flags & ...)
>   return gpio_reg_v2_convert();
>  return offset;
> }
>
>> +       switch (offset) {
>> +       case GPIO_INTMASK:
>> +               return GPIO_INTMASK_V2;
>> +       case GPIO_INTTYPE_LEVEL:
>> +               return GPIO_INTTYPE_LEVEL_V2;
>> +       case GPIO_INT_POLARITY:
>> +               return GPIO_INT_POLARITY_V2;
>> +       case GPIO_INTSTATUS:
>> +               return GPIO_INTSTATUS_V2;
>> +       case GPIO_PORTA_EOI:
>> +               return GPIO_PORTA_EOI_V2;
>> +       }
>> +
>> +       return offset;
>> +}
>
>> -       return gc->read_reg(reg_base + offset);
>> +       return gc->read_reg(reg_base + gpio_reg_convert(gpio, offset));
>
> I'm still not convinced why we can't use
>
> gc->read_reg = ..._read_reg_v2;
>
> It will be called only in case of v2.
>
> Sorry if I missed the point.

This gc->read_reg is from gpio_chip and it is assigned by the upper layer.

>
>>  static int dwapb_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
>> @@ -336,8 +366,8 @@ static void dwapb_configure_irqs(struct dwapb_gpio *gpio,
>>                 ct->chip.irq_disable = dwapb_irq_disable;
>>                 ct->chip.irq_request_resources = dwapb_irq_reqres;
>>                 ct->chip.irq_release_resources = dwapb_irq_relres;
>> -               ct->regs.ack = GPIO_PORTA_EOI;
>> -               ct->regs.mask = GPIO_INTMASK;
>> +               ct->regs.ack = gpio_reg_convert(gpio, GPIO_PORTA_EOI);
>> +               ct->regs.mask = gpio_reg_convert(gpio, GPIO_INTMASK);
>>                 ct->type = IRQ_TYPE_LEVEL_MASK;
>>         }
>>
>> @@ -520,6 +550,21 @@ static void dwapb_gpio_unregister(struct dwapb_gpio *gpio)
>>         return pdata;
>>  }
>
>
>> +static const struct of_device_id dwapb_of_match[] = {
>> +       { .compatible = "snps,dw-apb-gpio", .data = (void *)0},
>> +       { .compatible = "apm,xgene-gpio-v2", .data = (void *)GPIO_REG_OFFSET_V2},
>> +       { /* Sentinel */ }
>> +};
>> +MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> +
>> +static const struct acpi_device_id dwapb_acpi_match[] = {
>> +       {"HISI0181", 0},
>> +       {"APMC0D07", 0},
>> +       {"APMC0D81", GPIO_REG_OFFSET_V2},
>> +       { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
>> +
>
> Since you are adding stuff here, I would consider at least two patches:
> 1. Move tables up here
> 2. Add and enable V2

Do we really need to have a separate patch for move the table up?

>
> or even 3:
> 1. Move tables
> 2. Extend functionality
> 3. Add ACPI ID
>
>> +       of_devid = of_match_device(dwapb_of_match, dev);
>> +       if (of_devid) {
>
> Why not to follow the below pattern, i.e.
>
> if (dev.of_node) {
>       const struct of_device_id *of_id;
> ...
> } else if (has_acpi_companion(...)) {
> ...
> }
>
> ?
>
>> +               if (of_devid->data)
>> +                       gpio->flags = (uintptr_t)of_devid->data;
>
> Type inconsistency.
> (unsigned int) would work.

I tried and got this warning.
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]

Thanks
Hoan

>
>> +       } else {
>> +               const struct acpi_device_id *acpi_id;
>> +
>> +               acpi_id = acpi_match_device(dwapb_acpi_match, &pdev->dev);
>> +               if (acpi_id) {
>> +                       if (acpi_id->driver_data)
>> +                               gpio->flags = acpi_id->driver_data;
>> +               }
>> +       }
>
>> @@ -581,19 +642,6 @@ static int dwapb_gpio_remove(struct platform_device *pdev)
>
>> -static const struct of_device_id dwapb_of_match[] = {
>> -       { .compatible = "snps,dw-apb-gpio" },
>> -       { /* Sentinel */ }
>> -};
>> -MODULE_DEVICE_TABLE(of, dwapb_of_match);
>> -
>> -static const struct acpi_device_id dwapb_acpi_match[] = {
>> -       {"HISI0181", 0},
>> -       {"APMC0D07", 0},
>> -       { }
>> -};
>> -MODULE_DEVICE_TABLE(acpi, dwapb_acpi_match);
>> -
>
> --
> With Best Regards,
> Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ