* Re: [PATCH v2 2/5] pinctrl: uniphier: Add another audio I/O pin-mux settings for LD20
From: Linus Walleij @ 2019-08-05 11:19 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masahiro Yamada, open list:GPIO SUBSYSTEM, Linux ARM,
linux-kernel@vger.kernel.org, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1564465410-9165-3-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> This adds support for pinmux settings of aout1b group. This group includes
> audio I/O signals derived from xirq pins, and it is equivalent to "aout1"
> in functionality.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Patch applied with Masahiro's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 1/5] pinctrl: uniphier: Separate modem group from UART ctsrts group
From: Linus Walleij @ 2019-08-05 11:18 UTC (permalink / raw)
To: Kunihiko Hayashi
Cc: Masahiro Yamada, open list:GPIO SUBSYSTEM, Linux ARM,
linux-kernel@vger.kernel.org, Masami Hiramatsu, Jassi Brar
In-Reply-To: <1564465410-9165-2-git-send-email-hayashi.kunihiko@socionext.com>
On Tue, Jul 30, 2019 at 7:43 AM Kunihiko Hayashi
<hayashi.kunihiko@socionext.com> wrote:
> It depends on the board implementation whether to have each pins of
> CTS/RTS, and others for modem. So it is necessary to divide current
> uart_ctsrts group into uart_ctsrts and uart_modem groups.
>
> Since the number of implemented pins for modem differs depending
> on SoC, each uart_modem group also has a different number of pins.
>
> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Patch applied with Masahiro's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V4 2/2] gpio: inverter: document the inverter bindings
From: Linus Walleij @ 2019-08-05 11:15 UTC (permalink / raw)
To: Harish Jenny K N
Cc: Rob Herring, Bartosz Golaszewski, Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:GPIO SUBSYSTEM, Balasubramani Vivekanandan
In-Reply-To: <f1616784-4dbf-d0fa-b33e-c85fd569383a@mentor.com>
On Wed, Jul 10, 2019 at 10:28 AM Harish Jenny K N
<harish_kandiga@mentor.com> wrote:
> On 09/07/19 9:38 PM, Rob Herring wrote:
> >> This device tree binding models gpio inverters in the device tree to properly describe the hardware.
> >
> > We already define the active state of GPIOs in the consumers. If
> > there's an inverter in the middle, the consumer active state is simply
> > inverted. I don't agree that that is a hack as Linus said without some
> > reasoning why an inverter needs to be modeled in DT. Anything about
> > what 'userspace' needs is not a reason. That's a Linux thing that has
> > little to do with hardware description.
There is some level of ambition here which is inherently a bit fuzzy
around the edges. ("How long is the coast of Britain?" comes to mind.)
Surely the intention of device tree is not to recreate the schematic
in all detail. What we want is a model of the hardware that will
suffice for the operating system usecases.
But sometimes the DTS files will become confusing: why is this
component using GPIO_ACTIVE_LOW when another system
doesn't have that flag? If there is an explicit inverter, the
DTS gets more readable for a human.
But arguable that is case for adding inverters as syntactic
sugar in the DTS compiler instead...
> Yes we are talking about the hardware level inversions here.
> The usecase is for those without the gpio consumer driver.
> The usecase started with the concept of allowing an abstraction
> of the underlying hardware for the userland controlling program
> such that this program does not care whether the GPIO lines
> are inverted or not physically. In other words, a single userland
> controlling program can work unmodified across a variety of
> hardware platforms with the device tree mapping the logical
> to physical relationship of the GPIO hardware.
> I totally understand anything about what 'userspace' needs is
> not a reason, but this is not restricted to userspace alone as
> kernel drivers may need this just as much. Also we are
> just modelling/describing the hardware state in the device tree.
The kernel also has a need to model inverters and it has come
up from time to time, but I don't remember these instances
right off the top of my head.
I am not sure userspace needs are of zero concerns either.
Sure, for anything reimplementing what I have listed in
Documentation/driver-api/gpio/drivers-on-gpio.rst
it is just abuse of the ABI, but things like industrial control
systems and other one-offs have this need to run the
same binary unmodified for measuring the trigger level
of water in some tank or so, they can't create kernel
drivers for that kind of stuff.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] pinctrl: meson-g12a: add pwm_a on GPIOE_2 pinmux
From: Linus Walleij @ 2019-08-05 11:01 UTC (permalink / raw)
To: Neil Armstrong
Cc: open list:GPIO SUBSYSTEM, Linux ARM,
open list:ARM/Amlogic Meson..., linux-kernel@vger.kernel.org,
Kevin Hilman, Martin Blumenstingl
In-Reply-To: <20190729125838.6498-1-narmstrong@baylibre.com>
On Mon, Jul 29, 2019 at 2:58 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add the missing pinmux for the pwm_a function on the GPIOE_2 pin.
>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
From: Linus Walleij @ 2019-08-05 10:56 UTC (permalink / raw)
To: Marc Zyngier
Cc: Geert Uytterhoeven, christoffer.dall, Bartosz Golaszewski,
Alexander Graf, Peter Maydell, Paolo Bonzini, Magnus Damm,
open list:GPIO SUBSYSTEM, QEMU Developers, Linux-Renesas,
linux-kernel@vger.kernel.org
In-Reply-To: <dc2016d4-b06c-aa8e-2644-90caa40fbd63@arm.com>
On Mon, Aug 5, 2019 at 12:21 PM Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 01/08/2019 09:41, Linus Walleij wrote:
> > I would even go so far as to call it "gpio-virtualization" or
> > "gpio-virtualized" rather than "gpio-virtual" so it is clear what the
> > intended usecase is. We have a bit of confusion in the kernel
> > because people misuse the word "virtual" left and right, like for
> > "virtual IRQ number" (Linux IRQ numbers) which are just some
> > random number space, but not really "virtual", it's a semantic
> > disease similar to the confusion of using the word "manual" in
> > computer code.
>
> I'd drop the notion of "virtual" altogether. Nothing is virtual in this
> thing at all (the GPIOs are very real, from what I gather). Instead (and
> assuming I got it right, which is a long shot), what you have is a
> "synthetic" GPIO controller, made from the GPIOs belonging to other
> controllers. I'd call it "GPIO aggregator".
+1 on this.
Next thing that will predictably follow is a userspace ABI to
create those aggregators and have them go away if the
process creating it dies. Something to think of...
> > If QEMU can deal in a simple and straight-forward way with this
> > I see it quickly becoming a very useful tool for industrial automation
> > where you want to run each control system in isolation and just
> > respawn the virtual machine if something goes wrong.
>
> What the VMM (QEMU, kvmtool) would need to do is to present this as a
> "standard" GPIO IP, and use the backend aggregator to emulate it.
> Certainly doable. The nice part is that all the work is in userspace,
> and thus completely off my plate! ;-)
Yeah there is not really any "standard" GPIO, but if the user is running
e.g. a Versatile Express model, that has a PL061 GPIO, and then
a user would create an "aggregator GPIO" with say 8 lines and
QEMU would pick that up as /dev/gpiochipN and bind it inside
of QEMU to the lines of the virttualized PL061 GPIO controller,
so the machine thinks it is using a PL061 but in reality it is
just 8 GPIO lines on the host computer.
> You also may want to look into not emulating a standard IP, but use
> something virtio-based instead. The ACRN project seems to have something
> like this in progress, but I know nothing about it.
That sounds quite interesting as well.
Then the virtualized machine can just pick this "virtio GPIO" and
some command line switches or config file on the host can
set up and route a GPIO aggregator.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 01/20] pinctrl: tegra: Add suspend and resume support
From: Dmitry Osipenko @ 2019-08-05 10:50 UTC (permalink / raw)
To: Sowjanya Komatineni, thierry.reding, jonathanh, tglx, jason,
marc.zyngier, linus.walleij, stefan, mark.rutland
Cc: pdeschrijver, pgaikwad, sboyd, linux-clk, linux-gpio, jckuo,
josephl, talho, linux-tegra, linux-kernel, mperttunen, spatra,
robh+dt, devicetree, rjw, viresh.kumar, linux-pm
In-Reply-To: <1564607463-28802-2-git-send-email-skomatineni@nvidia.com>
01.08.2019 0:10, Sowjanya Komatineni пишет:
> This patch adds support for Tegra pinctrl driver suspend and resume.
>
> During suspend, context of all pinctrl registers are stored and
> on resume they are all restored to have all the pinmux and pad
> configuration for normal operation.
>
> Acked-by: Thierry Reding <treding@nvidia.com>
> Reviewed-by: Dmitry Osipenko <digetx@gmail.com>
> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com>
> ---
> drivers/pinctrl/tegra/pinctrl-tegra.c | 59 +++++++++++++++++++++++++++++++++++
> drivers/pinctrl/tegra/pinctrl-tegra.h | 3 ++
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/pinctrl/tegra/pinctrl-tegra.c b/drivers/pinctrl/tegra/pinctrl-tegra.c
> index 186ef98e7b2b..e3a237534281 100644
> --- a/drivers/pinctrl/tegra/pinctrl-tegra.c
> +++ b/drivers/pinctrl/tegra/pinctrl-tegra.c
> @@ -631,6 +631,58 @@ static void tegra_pinctrl_clear_parked_bits(struct tegra_pmx *pmx)
> }
> }
>
> +static size_t tegra_pinctrl_get_bank_size(struct device *dev,
> + unsigned int bank_id)
> +{
> + struct platform_device *pdev = to_platform_device(dev);
> + struct resource *res;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, bank_id);
> +
> + return resource_size(res) / 4;
> +}
> +
> +static int tegra_pinctrl_suspend(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + size_t bank_size;
> + unsigned int i, k;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
> + regs = pmx->regs[i];
> + for (k = 0; k < bank_size; k++)
> + *backup_regs++ = readl_relaxed(regs++);
> + }
> +
> + return pinctrl_force_sleep(pmx->pctl);
> +}
> +
> +static int tegra_pinctrl_resume(struct device *dev)
> +{
> + struct tegra_pmx *pmx = dev_get_drvdata(dev);
> + u32 *backup_regs = pmx->backup_regs;
> + u32 *regs;
> + size_t bank_size;
> + unsigned int i, k;
> +
> + for (i = 0; i < pmx->nbanks; i++) {
> + bank_size = tegra_pinctrl_get_bank_size(dev, i);
> + regs = pmx->regs[i];
> + for (k = 0; k < bank_size; k++)
> + writel_relaxed(*backup_regs++, regs++);
> + }
I'm now curious whether any kind of barrier is needed after the
writings. The pmx_writel() doesn't insert a barrier after the write and
seems it just misuses writel, which actually should be writel_relaxed()
+ barrier, IIUC.
It's also not obvious whether PINCTRL HW has any kind of write-FIFO and
thus maybe read-back + rmb() is needed in order ensure that writes are
actually completed.
The last thing which is not obvious is when the new configuration
actually takes into effect, does it happen immediately or maybe some
delay is needed?
[snip]
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: aspeed: Remove mention of deprecated compatibles
From: Linus Walleij @ 2019-08-05 10:48 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-aspeed, Lee Jones, Rob Herring, Mark Rutland, Joel Stanley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190724081313.12934-4-andrew@aj.id.au>
On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> Guide readers away from using the aspeed,g[45].* compatible patterns.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: aspeed: Document existence of deprecated compatibles
From: Linus Walleij @ 2019-08-05 10:47 UTC (permalink / raw)
To: Andrew Jeffery
Cc: linux-aspeed, Lee Jones, Rob Herring, Mark Rutland, Joel Stanley,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <20190724081313.12934-3-andrew@aj.id.au>
On Wed, Jul 24, 2019 at 10:13 AM Andrew Jeffery <andrew@aj.id.au> wrote:
> Otherwise they look odd in the face of not being listed in the bindings
> documents.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied to the pinctrl tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/3] ARM: dts: aspeed: Deprecate g[45]-style compatibles
From: Linus Walleij @ 2019-08-05 10:45 UTC (permalink / raw)
To: Joel Stanley
Cc: Andrew Jeffery, linux-aspeed, Lee Jones, Rob Herring,
Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org, open list:GPIO SUBSYSTEM
In-Reply-To: <CACPK8XcWK9Gf=pW5ds=3muoXHAWnyYfHcVSVh+anaTigtMO8yA@mail.gmail.com>
On Fri, Aug 2, 2019 at 8:15 AM Joel Stanley <joel@jms.id.au> wrote:
> > Joel, do you mind if Linus takes this series through the pinctrl tree, given
> > the fix to the devicetrees is patch 1/3?
>
> It depends if you plan more changes to that part of the device tree
> this merge window :)
>
> Linus, perhaps the safer option is for me to take 1/3 through my tree
> and you can take the rest through yours?
OK let's proceed like that.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/6] pinctrl: aspeed: Add AST2600 pinmux support
From: Linus Walleij @ 2019-08-05 10:42 UTC (permalink / raw)
To: Andrew Jeffery
Cc: open list:GPIO SUBSYSTEM, Rob Herring, Mark Rutland, Joel Stanley,
ryanchen.aspeed, johnny_huang, linux-aspeed,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, linux-kernel@vger.kernel.org
In-Reply-To: <20190711041942.23202-1-andrew@aj.id.au>
I applied this series now!
Thanks Andrew.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 1/6] pinctrl: sunxi: v3s: introduce support for V3
From: Linus Walleij @ 2019-08-05 10:36 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Maxime Ripard, Chen-Yu Tsai, Linux ARM,
linux-kernel@vger.kernel.org, linux-clk, open list:GPIO SUBSYSTEM,
linux-sunxi, Maxime Ripard
In-Reply-To: <20190728031227.49140-2-icenowy@aosc.io>
On Sun, Jul 28, 2019 at 5:13 AM Icenowy Zheng <icenowy@aosc.io> wrote:
> Introduce the GPIO pins that is only available on V3 (not on V3s) to the
> V3s pinctrl driver.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
> Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Patch applied to the pinctrl tree.
Ypurs,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: spmi-gpio: Mark expected switch fall-through
From: Linus Walleij @ 2019-08-05 10:33 UTC (permalink / raw)
To: Anders Roxell
Cc: Bjorn Andersson, Andy Gross, Heiko Stübner, MSM,
open list:GPIO SUBSYSTEM, linux-kernel@vger.kernel.org
In-Reply-To: <20190726112816.19723-1-anders.roxell@linaro.org>
On Fri, Jul 26, 2019 at 1:28 PM Anders Roxell <anders.roxell@linaro.org> wrote:
> When fall-through warnings was enabled by default the following warnings
> was starting to show up:
>
> ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c: In function ‘pmic_gpio_populate’:
> ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:815:20: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> pad->have_buffer = true;
> ~~~~~~~~~~~~~~~~~^~~~~~
> ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:816:2: note: here
> case PMIC_GPIO_SUBTYPE_GPIOC_4CH:
> ^~~~
> ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:820:20: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> pad->have_buffer = true;
> ~~~~~~~~~~~~~~~~~^~~~~~
> ../drivers/pinctrl/qcom/pinctrl-spmi-gpio.c:821:2: note: here
> case PMIC_GPIO_SUBTYPE_GPIOC_8CH:
> ^~~~
>
> Rework so that the compiler doesn't warn about fall-through.
>
> Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: rockchip: Mark expected switch fall-through
From: Linus Walleij @ 2019-08-05 10:32 UTC (permalink / raw)
To: Anders Roxell
Cc: Heiko Stübner, Bjorn Andersson, Andy Gross,
open list:GPIO SUBSYSTEM, Linux ARM,
open list:ARM/Rockchip SoC..., linux-kernel@vger.kernel.org
In-Reply-To: <20190726112812.19665-1-anders.roxell@linaro.org>
On Fri, Jul 26, 2019 at 1:28 PM Anders Roxell <anders.roxell@linaro.org> wrote:
> When fall-through warnings was enabled by default the following warning
> was starting to show up:
>
> ../drivers/pinctrl/pinctrl-rockchip.c: In function ‘rockchip_gpio_set_config’:
> ../drivers/pinctrl/pinctrl-rockchip.c:2783:3: warning: this statement may fall
> through [-Wimplicit-fallthrough=]
> rockchip_gpio_set_debounce(gc, offset, true);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/pinctrl/pinctrl-rockchip.c:2795:2: note: here
> default:
> ^~~~~~~
>
> Rework so that the compiler doesn't warn about fall-through. Add
> 'return -ENOTSUPP;' to match the comment.
>
> Fixes: d93512ef0f0e ("Makefile: Globally enable fall-through warning")
> Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 2/2] pinctrl: qdf2xxx: Switch to use device_property_count_uXX()
From: Andy Shevchenko @ 2019-08-05 10:24 UTC (permalink / raw)
To: Linus Walleij; +Cc: Bjorn Andersson, Andy Gross, MSM, open list:GPIO SUBSYSTEM
In-Reply-To: <CACRpkdZDeOXJzT6xXp_in0TYjYnE=wFJ8t0AO2bQ+4WMbRS=mw@mail.gmail.com>
On Mon, Aug 05, 2019 at 12:02:10PM +0200, Linus Walleij wrote:
> On Tue, Jul 23, 2019 at 9:27 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>
> > Use use device_property_count_uXX() directly, that makes code neater.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>
> Patch applied. (Same comment.)
Thanks, same comment.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v1 1/2] pinctrl: msm: Switch to use device_property_count_uXX()
From: Andy Shevchenko @ 2019-08-05 10:24 UTC (permalink / raw)
To: Linus Walleij; +Cc: Bjorn Andersson, Andy Gross, MSM, open list:GPIO SUBSYSTEM
In-Reply-To: <CACRpkda+0xQDcgkYg=x=d_Gk_EwvDE1iM+PKfo0sG7T-juQw6g@mail.gmail.com>
On Mon, Aug 05, 2019 at 12:01:11PM +0200, Linus Walleij wrote:
> On Tue, Jul 23, 2019 at 9:27 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>
> > Use use device_property_count_uXX() directly, that makes code neater.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> (...)
> > /* The number of GPIOs in the ACPI tables */
> > - len = ret = device_property_read_u16_array(pctrl->dev, "gpios", NULL,
> > - 0);
> > + len = ret = device_property_count_u16(pctrl->dev, "gpios");
>
> Patch applied (makes the kernel a better place) but:
Thanks!
> Can't we just use: gpiod_count(pctrl->dev, NULL); ?
Perhaps. I have no hardware to test and the question probably better to be
addressed to author(s) of the driver.
My scope is to convert to new extension to device property API, so, anyone who
will look for examples will not use the old approach.
> It's more to the point when counting gpios I think.
>
> However this driver is not includeing <linux/gpio/consumer.h>
> and is this "gpios" property really a consumer property? I think
> so but...
Sounds like this is an old driver and many questions to it applies.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver
From: Marc Zyngier @ 2019-08-05 10:21 UTC (permalink / raw)
To: Linus Walleij, Geert Uytterhoeven, christoffer.dall
Cc: Bartosz Golaszewski, Alexander Graf, Peter Maydell, Paolo Bonzini,
Magnus Damm, open list:GPIO SUBSYSTEM, QEMU Developers,
Linux-Renesas, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdY6qAUkQW4YHN9HskvZS2P-viWYTHSb28ECh1p+itU=4Q@mail.gmail.com>
On 01/08/2019 09:41, Linus Walleij wrote:
> Hi Geert!
>
> Thanks for this very interesting patch!
>
> On Fri, Jul 5, 2019 at 6:05 PM Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>
>> GPIO controllers are exported to userspace using /dev/gpiochip*
>> character devices. Access control to these devices is provided by
>> standard UNIX file system permissions, on an all-or-nothing basis:
>> either a GPIO controller is accessible for a user, or it is not.
>> Currently no mechanism exists to control access to individual GPIOs.
>
> Yes, I did that decision deliberately, as the chip is one device
> and the base system control is usually on a per-device granularity.
> At one point some people were asking for individual GPIO line
> permissions in the character device and my argument was something
> like why can't I have individual control over the access rights on a block
> device or the pixels on a graphics device then.
>
> Jokes aside, filesystems do provide access control over individual
> blocks on a block device in a way. So it is further up the stack.
>
> The same goes for this: something above the GPIO chip provide
> more granular access control, and as such it fits the need very well.
>
>> Hence add a virtual GPIO driver to aggregate existing GPIOs (up to 32),
>> and expose them as a new gpiochip. This is useful for implementing
>> access control, and assigning a set of GPIOs to a specific user.
>> Furthermore, it would simplify and harden exporting GPIOs to a virtual
>> machine, as the VM can just grab the full virtual GPIO controller, and
>> no longer needs to care about which GPIOs to grab and which not,
>> reducing the attack surface.
>
> Excellent approach.
>
> I would even go so far as to call it "gpio-virtualization" or
> "gpio-virtualized" rather than "gpio-virtual" so it is clear what the
> intended usecase is. We have a bit of confusion in the kernel
> because people misuse the word "virtual" left and right, like for
> "virtual IRQ number" (Linux IRQ numbers) which are just some
> random number space, but not really "virtual", it's a semantic
> disease similar to the confusion of using the word "manual" in
> computer code.
I'd drop the notion of "virtual" altogether. Nothing is virtual in this
thing at all (the GPIOs are very real, from what I gather). Instead (and
assuming I got it right, which is a long shot), what you have is a
"synthetic" GPIO controller, made from the GPIOs belonging to other
controllers. I'd call it "GPIO aggregator".
>
> Here it is however used correctly! (Maybe for the first time.)
>
>> Virtual GPIO controllers are instantiated by writing to the "new_device"
>> attribute file in sysfs:
>>
>> $ echo "<gpiochipA> <gpioA1> [<gpioA2> ...]"
>> "[, <gpiochipB> <gpioB1> [<gpioB2> ...]] ...]"
>> > /sys/bus/platform/drivers/gpio-virt-agg/new_device
>>
>> Likewise, virtual GPIO controllers can be destroyed after use:
>>
>> $ echo gpio-virt-agg.<N> \
>> > /sys/bus/platform/drivers/gpio-virt-agg/delete_device
>
> I suppose this is the right way to use sysfs.
>
> I would check with some virtualization people (paged Marc Zyngier
> and Christoffer Dall) so they can say whether this is the way any
> virtual machine wants to populate its local GPIO chip for
> use with a certain machine.
>
> If QEMU can deal in a simple and straight-forward way with this
> I see it quickly becoming a very useful tool for industrial automation
> where you want to run each control system in isolation and just
> respawn the virtual machine if something goes wrong.
What the VMM (QEMU, kvmtool) would need to do is to present this as a
"standard" GPIO IP, and use the backend aggregator to emulate it.
Certainly doable. The nice part is that all the work is in userspace,
and thus completely off my plate! ;-)
You also may want to look into not emulating a standard IP, but use
something virtio-based instead. The ACRN project seems to have something
like this in progress, but I know nothing about it.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Re: [PATCH] pinctrl: oxnas: remove set but not used variable 'arg'
From: Linus Walleij @ 2019-08-05 10:16 UTC (permalink / raw)
To: YueHaibing
Cc: Neil Armstrong, linux-kernel@vger.kernel.org, linux-oxnas,
Linux ARM, open list:GPIO SUBSYSTEM
In-Reply-To: <20190725142419.29892-1-yuehaibing@huawei.com>
On Thu, Jul 25, 2019 at 4:24 PM YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox810se_pinconf_set:
> drivers/pinctrl/pinctrl-oxnas.c:905:6: warning: variable arg set but not used [-Wunused-but-set-variable]
> drivers/pinctrl/pinctrl-oxnas.c: In function oxnas_ox820_pinconf_set:
> drivers/pinctrl/pinctrl-oxnas.c:944:6: warning: variable arg set but not used [-Wunused-but-set-variable]
>
> It is never used since commit 4b0c0c25fa79 ("pinctrl:
> oxnas: Add support for OX820"), so can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 3/3] pinctrl: mvebu: add additional variant for standalone CP115
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai, Linus Walleij, linux-gpio,
linux-arm-kernel, Grzegorz Jaszczyk, Marcin Wojtas,
Stefan Chulski, Yan Markman, Miquel Raynal
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Grzegorz Jaszczyk <jaz@semihalf.com>
With CP115 standalone modules, all MPP configuration are
possible. Handle this new possibility thanks to the new
"marvell,cp115-standalone-pinctrl" compatible property.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
[<miquel.raynal@bootlin.com>: mention the new compatible in the
commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
index 85ade9761885..17491b27e487 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
@@ -32,6 +32,7 @@ enum {
V_ARMADA_7K = BIT(0),
V_ARMADA_8K_CPM = BIT(1),
V_ARMADA_8K_CPS = BIT(2),
+ V_CP115_STANDALONE = BIT(3),
V_ARMADA_7K_8K_CPM = (V_ARMADA_7K | V_ARMADA_8K_CPM),
V_ARMADA_7K_8K_CPS = (V_ARMADA_7K | V_ARMADA_8K_CPS),
};
@@ -614,6 +615,10 @@ static const struct of_device_id armada_cp110_pinctrl_of_match[] = {
.compatible = "marvell,armada-8k-cps-pinctrl",
.data = (void *) V_ARMADA_8K_CPS,
},
+ {
+ .compatible = "marvell,cp115-standalone-pinctrl",
+ .data = (void *) V_CP115_STANDALONE,
+ },
{ },
};
@@ -655,16 +660,20 @@ static int armada_cp110_pinctrl_probe(struct platform_device *pdev)
switch (i) {
case 0 ... 31:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPS);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPS |
+ V_CP115_STANDALONE));
break;
case 32 ... 38:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPM |
+ V_CP115_STANDALONE));
break;
case 39 ... 43:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_8K_CPM |
+ V_CP115_STANDALONE));
break;
case 44 ... 62:
- mvebu_pinctrl_assign_variant(m, V_ARMADA_7K_8K_CPM);
+ mvebu_pinctrl_assign_variant(m, (V_ARMADA_7K_8K_CPM |
+ V_CP115_STANDALONE));
break;
}
}
--
2.20.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: cp110: document the new CP115 pinctrl compatible
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai, Linus Walleij, linux-gpio,
linux-arm-kernel, Grzegorz Jaszczyk, Marcin Wojtas,
Stefan Chulski, Yan Markman, Miquel Raynal
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Grzegorz Jaszczyk <jaz@semihalf.com>
A new compatible is going to be used for Armada CP115 pinctrl block,
document it.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
[<miquel.raynal@bootlin.com>: split the documentation out of the
driver commit]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
.../bindings/arm/marvell/cp110-system-controller.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
index 4db4119a6d19..f982a8ed9396 100644
--- a/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/marvell/cp110-system-controller.txt
@@ -78,8 +78,8 @@ Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt.
Required properties:
-- compatible: "marvell,armada-7k-pinctrl",
- "marvell,armada-8k-cpm-pinctrl" or "marvell,armada-8k-cps-pinctrl"
+- compatible: "marvell,armada-7k-pinctrl", "marvell,armada-8k-cpm-pinctrl",
+ "marvell,armada-8k-cps-pinctrl" or "marvell,cp115-standalone-pinctrl"
depending on the specific variant of the SoC being used.
Available mpp pins/groups and functions:
--
2.20.1
^ permalink raw reply related
* [PATCH 1/3] pinctrl: mvebu: Add CP110 missing pin functionality
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai, Linus Walleij, linux-gpio,
linux-arm-kernel, Grzegorz Jaszczyk, Marcin Wojtas,
Stefan Chulski, Yan Markman, Konstantin Porotchkin, Miquel Raynal
In-Reply-To: <20190805101607.29811-1-miquel.raynal@bootlin.com>
From: Konstantin Porotchkin <kostap@marvell.com>
Add missing definition for function 0xe on CP-110 MPP-62.
The pin function is Data Strobe for SDIO interface.
Signed-off-by: Konstantin Porotchkin <kostap@marvell.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
---
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
index 584952b2ba47..85ade9761885 100644
--- a/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
+++ b/drivers/pinctrl/mvebu/pinctrl-armada-cp110.c
@@ -597,7 +597,8 @@ static struct mvebu_mpp_mode armada_cp110_mpp_modes[] = {
MPP_FUNCTION(7, "uart0", "rxd"),
MPP_FUNCTION(8, "uart2", "rxd"),
MPP_FUNCTION(9, "sata0", "present_act"),
- MPP_FUNCTION(10, "ge", "mdc")),
+ MPP_FUNCTION(10, "ge", "mdc"),
+ MPP_FUNCTION(14, "sdio", "ds")),
};
static const struct of_device_id armada_cp110_pinctrl_of_match[] = {
--
2.20.1
^ permalink raw reply related
* [PATCH 0/3] CP115 pinctrl support
From: Miquel Raynal @ 2019-08-05 10:16 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: devicetree, Thomas Petazzoni, Gregory Clement, Antoine Tenart,
Maxime Chevallier, Nadav Haklai, Linus Walleij, linux-gpio,
linux-arm-kernel, Grzegorz Jaszczyk, Marcin Wojtas,
Stefan Chulski, Yan Markman, Miquel Raynal
Hello,
This is the second batch of changes (out of three) to support the brand
new Marvell CN9130 SoCs which are made of one AP807 and one CP115.
We add a new compatible (and the relevant support in the pinctrl
driver) before the addition in batch 3/3 of CN9130 SoCs DT using it.
1st batch was clocks support and is independent from this one.
Thanks,
Miquèl
Grzegorz Jaszczyk (2):
dt-bindings: cp110: document the new CP115 pinctrl compatible
pinctrl: mvebu: add additional variant for standalone CP115
Konstantin Porotchkin (1):
pinctrl: mvebu: Add CP110 missing pin functionality
.../arm/marvell/cp110-system-controller.txt | 4 ++--
drivers/pinctrl/mvebu/pinctrl-armada-cp110.c | 20 ++++++++++++++-----
2 files changed, 17 insertions(+), 7 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] pinctrl: stmfx: update pinconf settings
From: Linus Walleij @ 2019-08-05 10:15 UTC (permalink / raw)
To: Amelie Delaunay
Cc: Alexandre Torgue, Maxime Coquelin, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org, Linux ARM, linux-stm32
In-Reply-To: <1564053416-32192-1-git-send-email-amelie.delaunay@st.com>
On Thu, Jul 25, 2019 at 1:16 PM Amelie Delaunay <amelie.delaunay@st.com> wrote:
> From: Alexandre Torgue <alexandre.torgue@st.com>
>
> According to the following tab (coming from STMFX datasheet), updates
> have to done in stmfx_pinconf_set function:
>
> -"type" has to be set when "bias" is configured as "pull-up or pull-down"
> -PIN_CONFIG_DRIVE_PUSH_PULL should only be used when gpio is configured as
> output. There is so no need to check direction.
>
> DIR | TYPE | PUPD | MFX GPIO configuration
> ----|------|------|---------------------------------------------------
> 1 | 1 | 1 | OUTPUT open drain with internal pull-up resistor
> ----|------|------|---------------------------------------------------
> 1 | 1 | 0 | OUTPUT open drain with internal pull-down resistor
> ----|------|------|---------------------------------------------------
> 1 | 0 | 0/1 | OUTPUT push pull no pull
> ----|------|------|---------------------------------------------------
> 0 | 1 | 1 | INPUT with internal pull-up resistor
> ----|------|------|---------------------------------------------------
> 0 | 1 | 0 | INPUT with internal pull-down resistor
> ----|------|------|---------------------------------------------------
> 0 | 0 | 1 | INPUT floating
> ----|------|------|---------------------------------------------------
> 0 | 0 | 0 | analog (GPIO not used, default setting)
>
> Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: sprd: Combine the condition of MISC_PIN and COMMON_PIN
From: Linus Walleij @ 2019-08-05 10:13 UTC (permalink / raw)
To: Baolin Wang
Cc: Orson Zhai, Lyra Zhang, Vincent Guittot, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org
In-Reply-To: <17af5e761e0515d288a7ea4078ac9aa4a82a7a4e.1564048446.git.baolin.wang@linaro.org>
On Thu, Jul 25, 2019 at 11:56 AM Baolin Wang <baolin.wang@linaro.org> wrote:
> Since the follow-up pin design on Spreadtrum platform has some changes,
> some configuration of MISC_PIN moved to COMMON_PIN. To support current
> pin design and keep backward compatibility, we should combine the
> condition of MISC_PIN and COMMON_PIN to configure an individual pin.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: sprd: Change to use devm_platform_ioremap_resource()
From: Linus Walleij @ 2019-08-05 10:12 UTC (permalink / raw)
To: Baolin Wang
Cc: Orson Zhai, Lyra Zhang, Vincent Guittot, open list:GPIO SUBSYSTEM,
linux-kernel@vger.kernel.org
In-Reply-To: <ff410d312ed0047b5a36e5113daf7df78bcf1aa8.1564048446.git.baolin.wang@linaro.org>
On Thu, Jul 25, 2019 at 11:56 AM Baolin Wang <baolin.wang@linaro.org> wrote:
> The devm_platform_ioremap_resource() function wraps platform_get_resource()
> and devm_ioremap_resource() in a single helper, thus use it to simplify
> the code.
>
> Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v1 2/2] pinctrl: qdf2xxx: Switch to use device_property_count_uXX()
From: Linus Walleij @ 2019-08-05 10:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Bjorn Andersson, Andy Gross, MSM, open list:GPIO SUBSYSTEM
In-Reply-To: <20190723192738.68486-2-andriy.shevchenko@linux.intel.com>
On Tue, Jul 23, 2019 at 9:27 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> Use use device_property_count_uXX() directly, that makes code neater.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Patch applied. (Same comment.)
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox