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] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 4 Jul 2021 13:04:56 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Sergio Paracuellos <sergio.paracuellos@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        John Thomson <git@...nthomson.fastmail.com.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        NeilBrown <neil@...wn.name>,
        René van Dorst <opensource@...rst.com>,
        Nicholas Mc Guire <hofrat@...dl.org>
Subject: Re: [PATCH v2] gpio: mt7621: support gpio-line-names property

On Sun, Jul 4, 2021 at 11:06 AM Sergio Paracuellos
<sergio.paracuellos@...il.com> wrote:
> On Sun, Jul 4, 2021 at 7:57 AM Sergio Paracuellos
> <sergio.paracuellos@...il.com> wrote:
> > On Sat, Jul 3, 2021 at 9:36 PM Andy Shevchenko
> > <andy.shevchenko@...il.com> wrote:
> > > On Sat, Jul 3, 2021 at 3:51 PM Sergio Paracuellos
> > > <sergio.paracuellos@...il.com> wrote:
> > > > On Sat, Jul 3, 2021 at 2:05 PM Sergio Paracuellos
> > > > <sergio.paracuellos@...il.com> wrote:

...

> > > The below is closer to what I meant, yes. I have not much time to look
> > > into the details, but I don't have objections about what you suggested
> > > below. Additional comments there as well.
> >
> > Thanks for your time and review, Andy. Let's wait to see if Linus and
> > Bartosz are also ok with this approach.
> >
> > > > How about something like this?
> > > >
> > > > diff --git a/drivers/gpio/gpio-mt7621.c b/drivers/gpio/gpio-mt7621.c
> > > > index 82fb20dca53a..5854a9343491 100644
> > > > --- a/drivers/gpio/gpio-mt7621.c
> > > > +++ b/drivers/gpio/gpio-mt7621.c
> > > > @@ -241,6 +241,7 @@ mediatek_gpio_bank_probe(struct device *dev,
> > > >         if (!rg->chip.label)
> > > >                 return -ENOMEM;
> > > >
> > > > +       rg->chip.offset = bank * MTK_BANK_WIDTH;
> > > >         rg->irq_chip.name = dev_name(dev);
> > > >         rg->irq_chip.parent_device = dev;
> > > >         rg->irq_chip.irq_unmask = mediatek_gpio_irq_unmask;
> > >
> > > Obviously it should be a separate patch :-)
> >
> > Of course :). I will include one separate patch per driver using the
> > custom set names stuff: gpio-mt7621 and gpio-brcmstb. I don't know if
> > any other one is also following that wrong pattern.
>
> What if each gpiochip inside the same driver has a different width? In
> such a case (looking into the code seems to be the case for
> 'gpio-brcmstb', since driver's calculations per base are aligned with
> this code changes but when it is assigned every line name is taking
> into account gpio bank's width variable... If the only "client" of
> this code would be gpio-mt7621 (or those where base and width of the
> banks is the same) I don't know if changing core code makes sense...

As far as I understood the problem, the driver (either broadcom one or
mediatek) uses one GPIO description from which it internally splits to
a few GPIO chips. GPIO chips are kinda independent in that sense,
correct? So, if you put the index / offset field per GPIO chip before
creation, the problem is solved.  What did I miss?

-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists