All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <danilokrummrich@dk-develop.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@armlinux.org.uk>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Linux Input <linux-input@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
Date: Fri, 11 Aug 2017 13:05:20 +0200	[thread overview]
Message-ID: <180873724a3d2ee187178f12c09dfb9f@dk-develop.de> (raw)
In-Reply-To: <CACRpkda=bYacXmv8SoQu3wPoZW9v+j8myZnme=QpofD=Y-gYTg@mail.gmail.com>

On 2017-08-11 11:16, Linus Walleij wrote:
> On Thu, Aug 10, 2017 at 4:38 PM, Danilo Krummrich
> <danilokrummrich@dk-develop.de> wrote:
>> On 2017-08-07 18:22, Danilo Krummrich wrote:
>>>> 
>>>> > +static int ps2_gpio_write(struct serio *serio, unsigned char val)
>>>> > +{
>>>> > +       struct ps2_gpio_data *drvdata = serio->port_data;
>>>> > +
>>>> > +       drvdata->mode = PS2_MODE_TX;
>>>> > +       drvdata->tx_byte = val;
>>>> > +       /* Make sure ISR running on other CPU notice changes. */
>>>> > +       barrier();
>>>> 
>>>> This seems overengineered, is this really needed?
>>>> 
>>>> If we have races like this, the error is likely elsewhere, and 
>>>> should be
>>>> fixed in the GPIO driver MMIO access or so.
>>>> 
>>> Yes, seems it can be removed. I didn't saw any explicit barriers in 
>>> the
>>> GPIO
>>> driver (I'm testing on bcm2835), but it seems MMIO operations on SMP 
>>> archs
>>> does contain barriers. Not sure if all do. If some do not this 
>>> barrier
>>> might
>>> be needed to ensure ISR on other CPU notice the correct mode and byte 
>>> to
>>> send.
>>> 
>> I couldn't find any guarantee that the mode and tx_byte change is 
>> implicitly
>> covered by a barrier in this case. E.g. the bcm2835 driver does not 
>> make
>> sure stores are completed before the particular interrupt is enabled, 
>> except by
>> the fact that writel on ARM contains a wmb(). But this is nothing to 
>> rely on.
>> (Please tell me if I miss something.)
> 
> writel() should be guaranteeing that the values hit the hardware, wmb() 
> is
> spelled out "write memory barrier" I don't see what you're after here.
> 
Sorry for confusing wording. What I actually meant is if writel() is 
guaranteed
to make sure there's no reordering happening with other store 
operations. Of
course, in case of ARM it is sufficient as it contains a wmb. But I 
wasn't aware
that all writel() implementations guarantee this (if needed).
Thanks for clarification.

> If you think writel() doesn't do its job on some platform, then fix 
> writel()
> on that platform.
> 
> We can't randomly sprinkle things like this all over the kernel it 
> makes
> no sense.
> 
>> Therefore I would like to keep this barrier and replace it with 
>> smp_wmb() if
>> you are fine with that.
> 
> I do not think this is proper.
> 
As you explained writel() should guarantee no reordering with other 
store operations
(like drvdata->mode = PS2_MODE_TX in my case) is happening, I totally 
agree and will
fix this.

> Yours,
> Linus Walleij

Thanks,
Danilo

WARNING: multiple messages have this Message-ID (diff)
From: danilokrummrich@dk-develop.de (Danilo Krummrich)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serio: PS2 gpio bit banging driver for the serio bus
Date: Fri, 11 Aug 2017 13:05:20 +0200	[thread overview]
Message-ID: <180873724a3d2ee187178f12c09dfb9f@dk-develop.de> (raw)
In-Reply-To: <CACRpkda=bYacXmv8SoQu3wPoZW9v+j8myZnme=QpofD=Y-gYTg@mail.gmail.com>

On 2017-08-11 11:16, Linus Walleij wrote:
> On Thu, Aug 10, 2017 at 4:38 PM, Danilo Krummrich
> <danilokrummrich@dk-develop.de> wrote:
>> On 2017-08-07 18:22, Danilo Krummrich wrote:
>>>> 
>>>> > +static int ps2_gpio_write(struct serio *serio, unsigned char val)
>>>> > +{
>>>> > +       struct ps2_gpio_data *drvdata = serio->port_data;
>>>> > +
>>>> > +       drvdata->mode = PS2_MODE_TX;
>>>> > +       drvdata->tx_byte = val;
>>>> > +       /* Make sure ISR running on other CPU notice changes. */
>>>> > +       barrier();
>>>> 
>>>> This seems overengineered, is this really needed?
>>>> 
>>>> If we have races like this, the error is likely elsewhere, and 
>>>> should be
>>>> fixed in the GPIO driver MMIO access or so.
>>>> 
>>> Yes, seems it can be removed. I didn't saw any explicit barriers in 
>>> the
>>> GPIO
>>> driver (I'm testing on bcm2835), but it seems MMIO operations on SMP 
>>> archs
>>> does contain barriers. Not sure if all do. If some do not this 
>>> barrier
>>> might
>>> be needed to ensure ISR on other CPU notice the correct mode and byte 
>>> to
>>> send.
>>> 
>> I couldn't find any guarantee that the mode and tx_byte change is 
>> implicitly
>> covered by a barrier in this case. E.g. the bcm2835 driver does not 
>> make
>> sure stores are completed before the particular interrupt is enabled, 
>> except by
>> the fact that writel on ARM contains a wmb(). But this is nothing to 
>> rely on.
>> (Please tell me if I miss something.)
> 
> writel() should be guaranteeing that the values hit the hardware, wmb() 
> is
> spelled out "write memory barrier" I don't see what you're after here.
> 
Sorry for confusing wording. What I actually meant is if writel() is 
guaranteed
to make sure there's no reordering happening with other store 
operations. Of
course, in case of ARM it is sufficient as it contains a wmb. But I 
wasn't aware
that all writel() implementations guarantee this (if needed).
Thanks for clarification.

> If you think writel() doesn't do its job on some platform, then fix 
> writel()
> on that platform.
> 
> We can't randomly sprinkle things like this all over the kernel it 
> makes
> no sense.
> 
>> Therefore I would like to keep this barrier and replace it with 
>> smp_wmb() if
>> you are fine with that.
> 
> I do not think this is proper.
> 
As you explained writel() should guarantee no reordering with other 
store operations
(like drvdata->mode = PS2_MODE_TX in my case) is happening, I totally 
agree and will
fix this.

> Yours,
> Linus Walleij

Thanks,
Danilo

  reply	other threads:[~2017-08-11 11:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-31 22:24 [PATCH] serio: PS2 gpio bit banging driver for the serio bus Danilo Krummrich
     [not found] ` <20170731222452.22887-1-danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org>
2017-08-07  9:03   ` Linus Walleij
2017-08-07  9:03     ` Linus Walleij
2017-08-07 16:21     ` Danilo Krummrich
     [not found]     ` <CACRpkdYz_+soss4Rb9zMiP4eZZtXqjW_Xy7hH=wm1x2m_R9R3A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-08  2:49       ` Dmitry Torokhov
2017-08-08  2:49         ` Dmitry Torokhov
     [not found]     ` <20170807182207.348762301bf3d7f8509b1bf7@dk-develop.de>
     [not found]       ` <20170807182207.348762301bf3d7f8509b1bf7-q2z19idT6fYRctDU1SCqIg@public.gmane.org>
2017-08-10 14:38         ` Danilo Krummrich
2017-08-10 14:38           ` Danilo Krummrich
2017-08-11  9:16           ` Linus Walleij
2017-08-11  9:16             ` Linus Walleij
2017-08-11 11:05             ` Danilo Krummrich [this message]
2017-08-11 11:05               ` Danilo Krummrich
     [not found]             ` <CACRpkda=bYacXmv8SoQu3wPoZW9v+j8myZnme=QpofD=Y-gYTg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-08-17  9:09               ` Russell King - ARM Linux
2017-08-17  9:09                 ` Russell King - ARM Linux
2017-08-17  9:09                 ` Russell King - ARM Linux
     [not found]                 ` <20170817090908.GP20805-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2017-08-17 10:51                   ` Danilo Krummrich
2017-08-17 10:51                     ` Danilo Krummrich
2017-08-17 10:51                     ` Danilo Krummrich
2017-08-17 13:01                     ` Russell King - ARM Linux
2017-08-17 13:01                       ` Russell King - ARM Linux
2017-08-17 14:14                       ` Danilo Krummrich
2017-08-17 14:14                         ` Danilo Krummrich
2017-08-22 13:35                 ` Linus Walleij
2017-08-22 13:35                   ` Linus Walleij

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=180873724a3d2ee187178f12c09dfb9f@dk-develop.de \
    --to=danilokrummrich@dk-develop.de \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=will.deacon@arm.com \
    /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.