Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Linus Walleij]

On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich
<danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org> wrote:

> This driver provides PS2 serio bus support by implementing bit banging
> with the GPIO API. The GPIO pins, data and clock, can be configured with
> a node in the device tree or by static platform data.
>
> Writing to a device is supported as well, though it is not recommended as
> the timings to be halt given by libps2 are very tough and difficult to
> reach with bit banging. Therefore it can be configured (also in DT and
> pdata) whether the serio write function should be available for clients.
>
> This driver is for development purposes and not for productive use.
> However, this driver can be useful e.g. when no USB port is available or
> using old peripherals is desired as PS2 controllers getting rare.
>
> This driver was tested on a RPI1 and on Hikey960 and it worked well
> together with the atkbd driver.
>
> Signed-off-by: Danilo Krummrich <danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org>

> +++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt

When you add DT bindings you have to CC devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

> @@ -0,0 +1,20 @@
> +Device-Tree bindings for ps2 gpio driver
> +
> +Required properties:
> +       - compatible = "ps2-gpio";
> +       - gpios: data and clock gpio
> +
> +Optional properties:
> +       - ps2-gpio,write-enable: Indicates whether write function is provided
> +       to serio device. Most probably providing the write fn will not work,
> +       because of the tough timing libps2 requires.
> +
> +Example nodes:
> +
> +ps2@0 {
> +       compatible = "ps2-gpio";
> +       gpios = <&gpio 24 0 /* data */
> +                &gpio 23 0 /* clock */
> +               >;
> +       i2c-gpio,write-enable = <0>;
> +};

These look fine to me though.

> diff --git a/Documentation/gpio/drivers-on-gpio.txt b/Documentation/gpio/drivers-on-gpio.txt

Thanks for patching this!

> +config SERIO_GPIO_PS2
> +       tristate "GPIO PS/2 bit banging driver"
> +       help
> +         Say Y here if you want PS/2 bit banging support via GPIO.
> +
> +         To compile this driver as a module, choose M here: the
> +         module will be called gpio-ps2.
> +
> +         If you are unsure, say N.

As mentioned

depends on GPIOLIB
depends on OF

> +#include <linux/gpio.h>

Use only:

#include <linux/gpio/consumer.h>

> +#include <linux/of_gpio.h>

Should not be needed.


> +struct ps2_gpio_data {
> +       struct device *dev;
> +       struct serio *serio;
> +       unsigned char mode;
> +       unsigned int gpio_clk;
> +       unsigned int gpio_data;
> +       unsigned int write_enable;

Do not use the global GPIO number space, use GPIO descriptors.

Example:
drivers/input/keyboard/gpio_keys.c

> +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.

> +       disable_irq_nosync(drvdata->irq);
> +       gpio_direction_output(drvdata->gpio_clk, 0);

No use GPIO descriptors please.

> +       // dev_info(drvdata->dev, "recv bit %u: %u\n", cnt, data);

Delete comments or convert to dev_dbg()

> +static int of_ps2_gpio_get_props(struct device *dev,
> +                                struct ps2_gpio_data *drvdata)
> +{
> +       if (of_gpio_count(dev->of_node) < 2)
> +               return -ENODEV;
> +
> +       drvdata->gpio_data = of_get_gpio(dev->of_node, 0);
> +       drvdata->gpio_clk = of_get_gpio(dev->of_node, 1);
> +
> +       if (drvdata->gpio_data == -EPROBE_DEFER ||
> +           drvdata->gpio_clk == -EPROBE_DEFER)
> +               return -EPROBE_DEFER;
> +
> +       if (!gpio_is_valid(drvdata->gpio_data) ||
> +           !gpio_is_valid(drvdata->gpio_clk)) {
> +               dev_err(dev, "invalid GPIOs, data=%d, clk=%d\n",
> +                       drvdata->gpio_data, drvdata->gpio_clk);
> +               return -ENODEV;
> +       }

With GPIO descriptors you should just gpiod_get(dev, "foo", FLAG);
No need to poke around in the device tree like this.

Error checks and deferrals apply as usual though.

> +       error = devm_gpio_request(dev, drvdata->gpio_clk, "ps2 clk");
> +       if (error) {
> +               dev_err(dev, "failed to request gpio %u: %d",
> +                               drvdata->gpio_clk, error);
> +               goto err_free_serio;
> +       }
> +
> +       error = devm_gpio_request(dev, drvdata->gpio_data, "ps2 data");
> +       if (error) {
> +               dev_err(dev, "failed to request gpio %u: %d",
> +                               drvdata->gpio_data, error);
> +               goto err_free_serio;
> +       }

So devm_gpiod_get(...)

> +       gpio_direction_input(drvdata->gpio_clk);
> +       gpio_direction_input(drvdata->gpio_data);

And incidentallt then you can just specify GPIOD_IN as flag and
it will be set up for you.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Danilo Krummrich]

Hi Linus,

thanks for reviewing. Commented the ones which still holds.

On Mon, 7 Aug 2017 11:03:53 +0200
Linus Walleij <linus.walleij@linaro.org> wrote:

> On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich
> <danilokrummrich@dk-develop.de> wrote:
> 
> 
> When you add DT bindings you have to CC devicetree@vger.kernel.org
> 
I will do prospectively.

> > +#include <linux/gpio.h>
> 
> Use only:
> 
> #include <linux/gpio/consumer.h>
> 
Done in v6.

> > +#include <linux/of_gpio.h>
> 
> Should not be needed.
> 
> 
Removed in v6.

> > +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.

-- 
Danilo Krummrich <danilokrummrich@dk-develop.de>

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Dmitry Torokhov]

On Mon, Aug 07, 2017 at 11:03:53AM +0200, Linus Walleij wrote:
> On Tue, Aug 1, 2017 at 12:24 AM, Danilo Krummrich
> <danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org> wrote:
> 
> > +config SERIO_GPIO_PS2
> > +       tristate "GPIO PS/2 bit banging driver"
> > +       help
> > +         Say Y here if you want PS/2 bit banging support via GPIO.
> > +
> > +         To compile this driver as a module, choose M here: the
> > +         module will be called gpio-ps2.
> > +
> > +         If you are unsure, say N.
> 
> As mentioned
> 
> depends on GPIOLIB
> depends on OF

I do not think this driver has to depend on OF. It should use gpiod and
generic device properties.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Danilo Krummrich]

Hi Linus,

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.)
Therefore I would like to keep this barrier and replace it with 
smp_wmb() if you
are fine with that.

Regards,
Danilo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Linus Walleij]

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.

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.

Yours,
Linus Walleij

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Danilo Krummrich]

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

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Russell King - ARM Linux]

On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote:
> 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.

Incorrect.  writel() has a barrier which ensures that data written to
memory (eg, dma coherent memory) is visible to the hardware prior to
the write hitting the hardware.

There is no barrier to ensure that the write hits the hardware in a
timely manner - the write can be buffered by the buses, which will
delay it before it hits its destination.

PCI particularly buffers MMIO writes, and the requirement there has
always been that if you need the write to hit the hardware in a timely
fashion, you must perform a read-back to force the bus to deliver the
write (since a read is not allowed to overlap a write.)

The solution is never to use barrier() - barrier() is a _compiler_
barrier and does nothing for posted writes on hardware buses.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Danilo Krummrich]

On 2017-08-17 11:09, Russell King - ARM Linux wrote:
> On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote:
>> 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.
> 
> Incorrect.  writel() has a barrier which ensures that data written to
> memory (eg, dma coherent memory) is visible to the hardware prior to
> the write hitting the hardware.
> 
> There is no barrier to ensure that the write hits the hardware in a
> timely manner - the write can be buffered by the buses, which will
> delay it before it hits its destination.
> 
> PCI particularly buffers MMIO writes, and the requirement there has
> always been that if you need the write to hit the hardware in a timely
> fashion, you must perform a read-back to force the bus to deliver the
> write (since a read is not allowed to overlap a write.)
> 
> The solution is never to use barrier() - barrier() is a _compiler_
> barrier and does nothing for posted writes on hardware buses.

Thanks for clarification. I thought I just need a wmb() to make sure 
writel()
can not be reordered with another store operation. I wasn't aware that 
writel()
is defined to guarantee this on every arch.

That having the correct execution order is not enough on some buses 
because
of buffering is really something to be aware of, thanks again for 
pointing
this out.

So for the scenario I was concerned about I would expect the irqchip 
driver
guarantees the write actually hits the the hardware (if necessary read 
it
back) before the function (disable_irq_nosync()) returns, is that 
correct?
Though, having the need should be very unlikely.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Russell King - ARM Linux]

On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote:
> That having the correct execution order is not enough on some buses because
> of buffering is really something to be aware of, thanks again for pointing
> this out.

PCI guarantees the order of writes to a device, but there are situations
on SoCs where you can't rely on that - for instance, if the writes go
over different buses to different devices (eg, write to a peripheral
vs write to an interrupt controller.)

Even then, with interrupts delivered by message (eg, MSI) there's
issues.

> So for the scenario I was concerned about I would expect the irqchip driver
> guarantees the write actually hits the the hardware (if necessary read it
> back) before the function (disable_irq_nosync()) returns, is that correct?
> Though, having the need should be very unlikely.

Well, disable_irq_nosync() doesn't guarantee that the interrupt handler
isn't running - a CPU may have just received the interrupt and is just
entering the interrupt handler when disable_irq_nosync() returns.  The
hint is the "nosync" - there's no synchronisation.  If you need to
guarantee that the interrupt handler is not running, disable_irq() does
that.  By implication, however, disable_irq() can not be called from
within the same interrupt handler for the interrupt that is being
disabled.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Danilo Krummrich]

On 2017-08-17 15:01, Russell King - ARM Linux wrote:
> On Thu, Aug 17, 2017 at 12:51:33PM +0200, Danilo Krummrich wrote:
>> That having the correct execution order is not enough on some buses 
>> because
>> of buffering is really something to be aware of, thanks again for 
>> pointing
>> this out.
> 
> PCI guarantees the order of writes to a device, but there are 
> situations
> on SoCs where you can't rely on that - for instance, if the writes go
> over different buses to different devices (eg, write to a peripheral
> vs write to an interrupt controller.)
> 
> Even then, with interrupts delivered by message (eg, MSI) there's
> issues.
> 
>> So for the scenario I was concerned about I would expect the irqchip 
>> driver
>> guarantees the write actually hits the the hardware (if necessary read 
>> it
>> back) before the function (disable_irq_nosync()) returns, is that 
>> correct?
>> Though, having the need should be very unlikely.
> 
> Well, disable_irq_nosync() doesn't guarantee that the interrupt handler
> isn't running - a CPU may have just received the interrupt and is just
> entering the interrupt handler when disable_irq_nosync() returns.  The
> hint is the "nosync" - there's no synchronisation.  If you need to
> guarantee that the interrupt handler is not running, disable_irq() does
> that.  By implication, however, disable_irq() can not be called from
> within the same interrupt handler for the interrupt that is being
> disabled.
> 
Thanks again, I'm aware of that. As in my case the code could be called 
from
atomic context disable_irq() is not an option.

My main point is if it can be assumed that after disable_irq_nosync() 
returns
it is guaranteed, by convention, that the hardware was hit. But I really 
would
think so.

Re: [PATCH] serio: PS2 gpio bit banging driver for the serio bus

[Linus Walleij]

On Thu, Aug 17, 2017 at 11:09 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Fri, Aug 11, 2017 at 11:16:20AM +0200, Linus Walleij wrote:
>> 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.
>
> Incorrect.  writel() has a barrier which ensures that data written to
> memory (eg, dma coherent memory) is visible to the hardware prior to
> the write hitting the hardware.
>
> There is no barrier to ensure that the write hits the hardware in a
> timely manner - the write can be buffered by the buses, which will
> delay it before it hits its destination.
>
> PCI particularly buffers MMIO writes, and the requirement there has
> always been that if you need the write to hit the hardware in a timely
> fashion, you must perform a read-back to force the bus to deliver the
> write (since a read is not allowed to overlap a write.)
>
> The solution is never to use barrier() - barrier() is a _compiler_
> barrier and does nothing for posted writes on hardware buses.

Thanks Russell. I tend to forget things over time even though I have
some memory of this being spelled out to me in the past :(

Yours,
Linus Walleij