From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Jonathan Cameron <jic23@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2] gpio: winbond: add driver
Date: Wed, 27 Dec 2017 23:33:12 -0500 [thread overview]
Message-ID: <20171228043312.GA11117@sophia> (raw)
In-Reply-To: <CACRpkdYtGKWtodP9tb+ZdQ=dsSouvpMGeXRR_TDNV8hR53c+NQ@mail.gmail.com>
On Wed, Dec 27, 2017 at 12:16:53PM +0100, Linus Walleij wrote:
>On Wed, Dec 27, 2017 at 1:24 AM, William Breathitt Gray
><vilhelm.gray@gmail.com> wrote:
>
>> The issue seems to relate to the select GPIOLIB line for the STX104
>> Kconfig option (which has a ISA_BUS_API dependency). Switching GPIOLIB
>> to be a dependency, or alternatively selecting ISA_BUS_API, alleviates
>> the recursion.
>>
>> Linus, is my use of select GPIOLIB for the STX104 Kconfig option
>> appropriate in this context -- or should it instead be part of the
>> depends on line? The STX104 driver includes linux/gpio/driver.h and
>> makes use of the devm_gpiochip_add_data function to add support for some
>> minor auxililary GPIO lines on the STX104 device.
>
>In the STX104 case, it seems to be appropriate to
>select GPIOLIB, as it is a GPIO provider, not consumer.
>
>Usually I prefer that drivers just select what they need so I don't
>have to run around in the whole kernel tree and turn things on
>to the left and right before I can finally select my driver, but
>maybe that is just me.
>
>The other ISA GPIO drivers depends on ISA_BUS_API, I guess
>in difference from the symbol GPIOLIB it cannot be universally
>selected, so shouldn't this driver also just depends on ISA_BUS_API
>and select it from the machine or wherever?
When I initially submitted the PC/104 device drivers, I added
ISA_BUS_API to their depends on lines in order to mask the respective
drivers from users who do not have a PC/104 bus on their system; in
retrospect, I shouldn't have done it this way. I later added a proper
CONFIG_PC104 option to achieve the masking I initially intended.
The correct semantic would be to treat ISA_BUS_API as we do GPIOLIB:
allow drivers to select it when needed. The reason is that
CONFIG_ISA_BUS_API simply enables the compilation of the
drivers/base/isa.c file. This file has no other Kconfig dependencies and
simply provides a thin layer of code to eliminate some boilerplate
common to ISA-style device drivers; no hardware interactions occur
within this code, just pure software abstractions.
Given that CONFIG_PC104 now fulfills the original purpose of adding
ISA_BUS_API to the depends on line for the PC/104 device drivers, and
that ISA_BUS_API can be selected as necessary with no danger to the
integrity of the system, I think it would be appropriate to change all
the existing ISA_BUS_API depends on lines to respective select lines.
Does that logic make sense?
William Breathitt Gray
>
>Yours,
>Linus Walleij
next prev parent reply other threads:[~2017-12-28 4:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-22 18:58 [PATCH v2] gpio: winbond: add driver Maciej S. Szmigiero
2017-12-24 22:42 ` William Breathitt Gray
2017-12-25 0:00 ` Maciej S. Szmigiero
2017-12-25 14:48 ` Maciej S. Szmigiero
2017-12-27 0:24 ` William Breathitt Gray
2017-12-27 11:16 ` Linus Walleij
2017-12-28 4:33 ` William Breathitt Gray [this message]
2017-12-28 12:52 ` Linus Walleij
2017-12-27 18:42 ` Maciej S. Szmigiero
2017-12-28 4:58 ` William Breathitt Gray
2017-12-28 22:45 ` Maciej S. Szmigiero
2017-12-28 15:12 ` Andy Shevchenko
2017-12-28 23:44 ` Maciej S. Szmigiero
2017-12-29 10:27 ` Andy Shevchenko
2017-12-29 16:09 ` William Breathitt Gray
2017-12-30 21:02 ` Maciej S. Szmigiero
2017-12-30 21:02 ` Maciej S. Szmigiero
2017-12-28 15:18 ` Andy Shevchenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171228043312.GA11117@sophia \
--to=vilhelm.gray@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=jic23@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.