From: "Janusz Użycki" <j.uzycki@elproma.com.pl>
To: "Alexandre Courbot" <gnurou@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
linux-serial@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH 2/4] gpiolib: use const parameters when possible
Date: Tue, 25 Nov 2014 10:36:43 +0100 [thread overview]
Message-ID: <54744DAB.1010603@elproma.com.pl> (raw)
In-Reply-To: <CAAVeFuJ8=PdV8oiazVVcyrO3Kx4mV6GphxHCGEGX9ooMuoBWtA@mail.gmail.com>
Hello,
W dniu 2014-11-25 o 08:37, Alexandre Courbot pisze:
> On Wed, Nov 19, 2014 at 7:09 PM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>> Hello Alexandre,
>>
>> On Wed, Nov 19, 2014 at 06:07:50PM +0900, Alexandre Courbot wrote:
>>> On Wed, Nov 19, 2014 at 6:02 PM, Uwe Kleine-König
>>> <u.kleine-koenig@pengutronix.de> wrote:
>>>> I'd make gpiod_get_direction static and only use it to fill in
>>>> /sys/kernel/debug/gpio.
>>> That's very tempting. I see only atmel_serial.c using this function,
>>> and there is no gpio_get_direction() declared anywhere so no user of
>>> this either. I'm not sure what I was thinking when I decided to export
>>> it?
>> In next there is also drivers/tty/serial/mxs-auart.c.
> Ok. I think we can get rid of gpiod_get_direction() if
> serial_mctrl_gpio implements its own way to query the direction (maybe
> using a bitmap in the mctrl_gpios and a mctrl_gpio_get_direction()
> function that queries that map). Using gpiod_get_direction() is just
> too unreliable.
good idea
>
> Janusz, since your change for mxs-auart is in -next, would you mind
> amending it to do this? Then we could do the same for atmel_serial and
> remove gpiod_get_direction() from the public GPIO interface. This
> function would do more harm than good anyway.
After a discussion I prepared RFC patch set to avoid the function.
You will find it here [1]:
("[RFC PATCH 1/2] serial: mctrl-gpio: Add irqs helpers for input lines")
("[RFC PATCH 2/2] serial: mxs-auart: use helpers for gpio irqs")
and the function was moved for debug only:
("[PATCH v3] gpio: mxs: implement get_direction callback")
Affected drivers by the patch set in the next are:
- atmel_serial
- mxs-auart
- clps711x (very basic usage)
The RFC patch set removes the inconvenient function from mxs-auart as
example.
I didn't prepared a patch for atmel_serial because I wait for comments about
mctrl_gpio_is_gpio() function to differentiate if line is GPIO or native in
enable/disable_ms() callbacks.
I also can't test it for other devices than mxs (mx28).
[1] http://www.spinics.net/lists/arm-kernel/msg378444.html
best regards
Janusz
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: "Janusz Użycki" <j.uzycki@elproma.com.pl>
To: "Alexandre Courbot" <gnurou@gmail.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: Grant Likely <grant.likely@secretlab.ca>,
Linus Walleij <linus.walleij@linaro.org>,
linux-serial@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alexandre Courbot <acourbot@nvidia.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>
Subject: Re: [PATCH 2/4] gpiolib: use const parameters when possible
Date: Tue, 25 Nov 2014 10:36:43 +0100 [thread overview]
Message-ID: <54744DAB.1010603@elproma.com.pl> (raw)
In-Reply-To: <CAAVeFuJ8=PdV8oiazVVcyrO3Kx4mV6GphxHCGEGX9ooMuoBWtA@mail.gmail.com>
Hello,
W dniu 2014-11-25 o 08:37, Alexandre Courbot pisze:
> On Wed, Nov 19, 2014 at 7:09 PM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>> Hello Alexandre,
>>
>> On Wed, Nov 19, 2014 at 06:07:50PM +0900, Alexandre Courbot wrote:
>>> On Wed, Nov 19, 2014 at 6:02 PM, Uwe Kleine-König
>>> <u.kleine-koenig@pengutronix.de> wrote:
>>>> I'd make gpiod_get_direction static and only use it to fill in
>>>> /sys/kernel/debug/gpio.
>>> That's very tempting. I see only atmel_serial.c using this function,
>>> and there is no gpio_get_direction() declared anywhere so no user of
>>> this either. I'm not sure what I was thinking when I decided to export
>>> it?
>> In next there is also drivers/tty/serial/mxs-auart.c.
> Ok. I think we can get rid of gpiod_get_direction() if
> serial_mctrl_gpio implements its own way to query the direction (maybe
> using a bitmap in the mctrl_gpios and a mctrl_gpio_get_direction()
> function that queries that map). Using gpiod_get_direction() is just
> too unreliable.
good idea
>
> Janusz, since your change for mxs-auart is in -next, would you mind
> amending it to do this? Then we could do the same for atmel_serial and
> remove gpiod_get_direction() from the public GPIO interface. This
> function would do more harm than good anyway.
After a discussion I prepared RFC patch set to avoid the function.
You will find it here [1]:
("[RFC PATCH 1/2] serial: mctrl-gpio: Add irqs helpers for input lines")
("[RFC PATCH 2/2] serial: mxs-auart: use helpers for gpio irqs")
and the function was moved for debug only:
("[PATCH v3] gpio: mxs: implement get_direction callback")
Affected drivers by the patch set in the next are:
- atmel_serial
- mxs-auart
- clps711x (very basic usage)
The RFC patch set removes the inconvenient function from mxs-auart as
example.
I didn't prepared a patch for atmel_serial because I wait for comments about
mctrl_gpio_is_gpio() function to differentiate if line is GPIO or native in
enable/disable_ms() callbacks.
I also can't test it for other devices than mxs (mx28).
[1] http://www.spinics.net/lists/arm-kernel/msg378444.html
best regards
Janusz
next prev parent reply other threads:[~2014-11-25 9:36 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 7:02 [PATCH 0/4] gpiolib: some fixup patches Alexandre Courbot
2013-02-13 7:02 ` [PATCH 1/4] gpiolib: check descriptors validity before use Alexandre Courbot
2013-02-13 22:49 ` Ryan Mallon
2013-02-14 3:00 ` Alexandre Courbot
2013-02-13 7:03 ` [PATCH 2/4] gpiolib: use const parameters when possible Alexandre Courbot
2014-11-17 9:09 ` Uwe Kleine-König
2014-11-19 8:33 ` Alexandre Courbot
2014-11-19 8:44 ` Uwe Kleine-König
2014-11-19 8:57 ` Alexandre Courbot
2014-11-19 9:02 ` Uwe Kleine-König
2014-11-19 9:07 ` Alexandre Courbot
2014-11-19 10:09 ` Uwe Kleine-König
2014-11-25 7:37 ` Alexandre Courbot
2014-11-25 7:37 ` Alexandre Courbot
2014-11-25 9:36 ` Janusz Użycki [this message]
2014-11-25 9:36 ` Janusz Użycki
2013-02-13 7:03 ` [PATCH 3/4] gpiolib: move comment to right function Alexandre Courbot
2013-02-13 7:03 ` [PATCH 4/4] gpiolib: rename local offset variables to "hwgpio" Alexandre Courbot
2013-02-13 22:54 ` Ryan Mallon
2013-02-14 3:11 ` Alexandre Courbot
2013-02-13 7:03 ` Alexandre Courbot
-- strict thread matches above, loose matches on Subject: below --
2013-02-15 5:46 [PATCH v2 0/4] gpiolib: some fixup patches Alexandre Courbot
2013-02-15 5:46 ` [PATCH 2/4] gpiolib: use const parameters when possible Alexandre Courbot
2013-02-26 17:49 ` Grant Likely
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=54744DAB.1010603@elproma.com.pl \
--to=j.uzycki@elproma.com.pl \
--cc=acourbot@nvidia.com \
--cc=gnurou@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
/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.