Re: [PATCH] gpio: Update TODO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



wt., 7 sty 2020 o 22:26 Linus Walleij <linus.walleij@xxxxxxxxxx> napisał(a):
>
> Drop the completed item: hierarchical irqchip helpers. Add
> motivation for gpio descriptor refactoring. Extend the list of
> stuff to do. Minor fixups.
>
> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>

Hi,

thanks for doing this, I'm seeing just a couple typos here and there.
They're probably not important anyway as it's a "temporary" (right...)
TODO item.

> ---
>  drivers/gpio/TODO | 46 +++++++++++++++++++++++++++++++++++++++++-----
>  1 file changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO
> index 76f8c7ff18ff..342285ecdb08 100644
> --- a/drivers/gpio/TODO
> +++ b/drivers/gpio/TODO
> @@ -10,6 +10,28 @@ approach. This means that GPIO consumers, drivers and machine descriptions
>  ideally have no use or idea of the global GPIO numberspace that has/was
>  used in the inception of the GPIO subsystem.
>
> +The number space issue is thesame as to why irq is moving away from irq

s/thesame/the same/

Also: should number space be two separate...

> +numbers to IRQ descriptors.
> +
> +The underlying motivation for this is that the GPIO number space has become
> +unmanageable: machine board files tend to become full of macros trying to
> +establish the numberspace at compile-time, making it hard to add any numbers
> +in the middle (such as if you missed a pin on a chip) without the numberspace

...or a single word anyway? I'm not a native speaker, so I honestly don't know.

> +breaking.
> +
> +Machine descriptions such as device tree or ACPI does not have a concept of the

I think it should be "machine descriptions (...) do not have" but
again: don't take my word for it.

> +Linux GPIO number as those descriptions are external to the Linux kernel
> +and treat GPIO lines as abstract entities.
> +
> +The runtime-assigned GPIO number space (what you get if you assign the GPIO
> +base as -1 in struct gpio_chip) has also became unpredictable due to factors
> +such as probe ordering and the introduction of -EPROBE_DEFER making probe
> +ordering of independent GPIO chips essentially upredictable, as their base

s/upredictableunpredictable/

Bart




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux