From: William Breathitt Gray <william.gray@linaro.org>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Fred Eckert <Frede@cmslaser.com>,
John Hentges <jhentges@accesio.com>,
Jay Dolan <jay.dolan@accesio.com>
Subject: Re: [PATCH v2 1/6] gpio: i8255: Introduce the i8255 module
Date: Mon, 11 Jul 2022 22:31:09 -0400 [thread overview]
Message-ID: <Yszc7cvyB37b8UHg@fedora> (raw)
In-Reply-To: <CAHp75VdM7QoBfcsQ-S4OEn2ZLnFH+0HfLY44FcRQC+_cw+UXzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]
On Fri, Jul 08, 2022 at 04:40:01PM +0200, Andy Shevchenko wrote:
> On Fri, Jul 8, 2022 at 1:16 AM William Breathitt Gray
> <william.gray@linaro.org> wrote:
> >
> > Exposes consumer functions providing support for Intel 8255 Programmable
> > Peripheral Interface devices. A CONFIG_GPIO_I8255 Kconfig option is
> > introduced; modules wanting access to these functions should select this
> > Kconfig option.
>
> Spent much time with these chips in my teenage times :-)
>
> Very good written library, see my comments below.
>
> ...
>
> > +#include <linux/compiler_types.h>
>
> Should be simple types.h as you are using u8, etc.
Ack.
> > +#include <linux/err.h>
> > +#include <linux/export.h>
>
> > +#include <linux/gpio/i8255.h>
>
> gpio/driver.h ?
>
> And since it belongs to GPIO, I would group them and move after all
> other include/* to emphasize the relationship.
>
> Also, why is it in the global header folder? Do you expect some
> drivers outside of drivers/gpio/? Maybe we can move after when the
> user comes?
I think gpio/driver.h does make more sense for now since all the users
of library are located under drivers/gpio/. I'll move the header code
into gpio/driver.h then and adjust the includes accordingly.
> > +#include <linux/io.h>
> > +#include <linux/module.h>
>
> ...
>
> > +#define I8255_CONTROL_PORTCLOWER_DIRECTION BIT(0)
> > +#define I8255_CONTROL_PORTCUPPER_DIRECTION BIT(3)
>
> Missed underscore.
Ack.
> ...
>
> > +static u8 i8255_direction_mask(const unsigned long offset)
> > +{
> > + const unsigned long io_port = offset / 8;
> > + const unsigned long ppi_port = io_port % 3;
> > +
> > + switch (ppi_port) {
> > + case I8255_PORTA:
> > + return I8255_CONTROL_PORTA_DIRECTION;
> > + case I8255_PORTB:
> > + return I8255_CONTROL_PORTB_DIRECTION;
> > + case I8255_PORTC:
> > + /* Port C can be configured by nibble */
>
> > + if (offset % 8 > 3)
>
> I would move it to the local definition block close to offset/8. On
> some architectures this may give one assembly instruction for two
> variables.
Ack.
> > + return I8255_CONTROL_PORTCUPPER_DIRECTION;
> > + return I8255_CONTROL_PORTCLOWER_DIRECTION;
> > + default:
> > + /* Should never reach this path */
> > + return 0;
> > + }
> > +}
>
> > +void i8255_direction_input(struct i8255 __iomem *const ppi,
> > + u8 *const control_state, const unsigned long offset)
> > +{
> > + const unsigned long io_port = offset / 8;
> > + const unsigned long group = io_port / 3;
> > +
> > + control_state[group] |= I8255_CONTROL_MODE_SET;
> > + control_state[group] |= i8255_direction_mask(offset);
> > +
> > + iowrite8(control_state[group], &ppi[group].control);
>
> No I/O serialization? Can this be accessed during interrupt? (It may
> be that the code is correct, but please go through it and check with a
> question "can this register be accessed during IRQ and if yes, will
> the user get the correct / meaningful data?")
Writing to the 8255 control register for the device shouldn't be a
problem, but we do have a race condition with the control_state[group]
value. This value is accessed and modified in other functions (e.g. the
i8255_direction_output() right below) so if an interrupt occurs the
value could end up clobbered before it's written.
I'm not sure what the best approach would be here. In the subsequent
patches I have the GPIO drivers take a lock before calling these i8255_*
functions in order to synchronize access to those state arrays. Do you
think it would be better to move the sychronization lock acquisition
internally to the i8255_* functions here?
> > +}
> > +EXPORT_SYMBOL_GPL(i8255_direction_input);
>
> Make it with a namespace. Ditto for the rest.
Ack.
William Breathitt Gray
> --
> With Best Regards,
> Andy Shevchenko
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-07-12 2:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 18:10 [PATCH v2 0/6] gpio: Implement and utilize register structures for ISA drivers William Breathitt Gray
2022-07-07 18:10 ` [PATCH v2 1/6] gpio: i8255: Introduce the i8255 module William Breathitt Gray
2022-07-08 14:40 ` Andy Shevchenko
2022-07-12 2:31 ` William Breathitt Gray [this message]
2022-07-11 13:02 ` Linus Walleij
2022-07-12 3:06 ` William Breathitt Gray
2022-07-13 7:37 ` Bartosz Golaszewski
2022-07-13 10:10 ` Andy Shevchenko
2022-07-13 10:49 ` William Breathitt Gray
2022-07-13 11:38 ` Andy Shevchenko
2022-07-07 18:10 ` [PATCH v2 2/6] gpio: 104-dio-48e: Implement and utilize register structures William Breathitt Gray
2022-07-07 18:10 ` [PATCH v2 3/6] gpio: 104-idi-48: " William Breathitt Gray
2022-07-07 18:10 ` [PATCH v2 4/6] gpio: gpio-mm: " William Breathitt Gray
2022-07-07 18:10 ` [PATCH v2 5/6] gpio: 104-idio-16: " William Breathitt Gray
2022-07-07 18:10 ` [PATCH v2 6/6] gpio: ws16c48: " William Breathitt Gray
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=Yszc7cvyB37b8UHg@fedora \
--to=william.gray@linaro.org \
--cc=Frede@cmslaser.com \
--cc=andy.shevchenko@gmail.com \
--cc=brgl@bgdev.pl \
--cc=jay.dolan@accesio.com \
--cc=jhentges@accesio.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.