Messages in this thread | | | Date | Mon, 13 Jan 2014 12:15:07 +0000 | Subject | Re: [PATCH 3/3] gpio: MAX6650/6651 support | From | Laszlo Papp <> |
| |
On Mon, Jan 13, 2014 at 9:48 AM, Linus Walleij <linus.walleij@linaro.org> wrote: > On Mon, Jan 13, 2014 at 10:22 AM, Laszlo Papp <lpapp@kde.org> wrote: > >> I was giving a second thought to this. Would it be acceptable to add >> the gpio driver now, and once the need arises, add the pinctrl thin >> layer on top of it? > > I will not accept the platform data setting the pull-ups.
OK.
>> My concern is that I would not use anything else >> than the gpio functionality of these pins. It would be a needless >> additional work (i.e. investment) for my project and employer. > > But you are still expecting me as a subsystem maintainer to > take responsibility of this driver for as long as I have this role?
Well, since we need to make sure that our product rocks and rolls, me and my employer would need be committed for a quite while, but I can understand where you are coming from.
> Rewriting code is a natural part of the community process, > noone claimed it would be easy ;-)
Yes, it is difficult, especially for a C++/OOP person like me... I am trying to do my best.
>> Perhaps, the layer on top of that can be added later without any >> drawback if anyone ever finds the need to have more functionality >> supported by these pins? > > Your driver already supports setting the pulls using a > *custom* platform data field. This is not OK, and shall be > implemented using the pin control subsystem. I will not > merge drivers using custom platform data fields like this. > > The reason that the pin control subsystem even existed was > that at the time my drivers were NACKed because I tried to > shoehorn pin control into the GPIO subsystem, and as a > result now we have an apropriate subsystem for it, so please > use it.
OK, thanks.
| |