Re: [PATCH v2] gpiolib: add hogs support for machine code
On Thu, Apr 26, 2018 at 6:42 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: > 2018-04-26 14:07 GMT+02:00 Linus Walleij <linus.wall...@linaro.org>: >> On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: >> >>> Board files constitute a significant part of the users of the legacy >>> GPIO framework. In many cases they only export a line and set its >>> desired value. We could use GPIO hogs for that like we do for DT and >>> ACPI but there's no support for that in machine code. >>> >>> This patch proposes to extend the machine.h API with support for >>> registering hog tables in board files. >>> >>> Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl> >>> --- >>> v1 -> v2: >>> - kbuild bot complains about enum gpiod_flags having incomplete type >>> although it builds fine for me locally: change the type of dflags >>> to int >> >> I like the idea and thinking behind this patch, so patch applied. >> >> It's a bit of code to carry, so if it doesn't see any use, I will simply >> revert it :) >> >> But I bet you intend to follow up with some machine patches >> and then it is immediately worth it. > > Yes, I'll be submitting patches removing the legacy gpio calls for > boards in mach-davinci. Awesome, thanks! (I guess they should all be converted to device tree though, hope that will happen...) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpiolib: add hogs support for machine code
On Thu, Apr 12, 2018 at 10:00 PM, Christian Lamparter <chunk...@gmail.com> wrote: > The problem is that unlike native gpio-controllers, pinctrls need > to have a "pin/gpio range" defined before any gpio-hogs can be added. Indeed. But the primary use case (correct me if I am wrong Bartosz) is to clean up old boardfile code. Old boardfiles belong to equally old boards. They very often do not have pin control, just GPIO, and they very often have custom code that just issue gpio_get(), gpio_* etc to set up hogs. So this will be able to replace all such boilerplate with some hog table for each boardfile and be done with it. I.e. they have only drivers/gpio/gpio-foo.c and no pin control driver in 9 cases out of 10. Cases do exist where they use pin control with board files. Those are rare. But they will have problems. Some machine descriptor tables are used on modern archs and the most prominent is x86 Intel. However the Intel pin control driver is one of those that (IIRC) will actually survive this (i.e. it doesn not have this bug). They are not even using DT, they use ACPI. > So what will happen is that you'll get an > "gpiochip_machine_hog: unable to hog GPIO line $LABEL $GPIONR -517" error > for every single gpio-hog and wonder why :(. Hm maybe we can simply improbe the error messages so people realize they have to go and fix their pin control driver(s)? OK maybe a bit whimsical comment from me here... :/ Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpiolib: add hogs support for machine code
On Tue, Apr 10, 2018 at 10:30 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: > Board files constitute a significant part of the users of the legacy > GPIO framework. In many cases they only export a line and set its > desired value. We could use GPIO hogs for that like we do for DT and > ACPI but there's no support for that in machine code. > > This patch proposes to extend the machine.h API with support for > registering hog tables in board files. > > Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl> > --- > v1 -> v2: > - kbuild bot complains about enum gpiod_flags having incomplete type > although it builds fine for me locally: change the type of dflags > to int I like the idea and thinking behind this patch, so patch applied. It's a bit of code to carry, so if it doesn't see any use, I will simply revert it :) But I bet you intend to follow up with some machine patches and then it is immediately worth it. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 09/10] gpio: Add a driver for Cadence I3C GPIO expander
On Fri, Mar 30, 2018 at 9:47 AM, Boris Brezillon
<boris.brezil...@bootlin.com> wrote:
> Add a driver for Cadence I3C GPIO expander.
>
> Signed-off-by: Boris Brezillon <boris.brezil...@bootlin.com>
This is pretty much OK, and I don't want to raise the bar
even higher for you to get this code into the kernel, so:
Acked-by: Linus Walleij <linus.wall...@linaro.org>
The following is an observation for future improvement:
> +static int cdns_i3c_gpio_read_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
> + u8 *val)
> +{
> + struct i3c_priv_xfer xfers[] = {
> + {
> + .len = sizeof(reg),
> + .data.out = ,
> + },
> + {
> + .rnw = true,
> + .len = sizeof(*val),
> + .data.in = val,
> + },
> + };
> +
> + return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
> + ARRAY_SIZE(xfers));
> +}
> +
> +static int cdns_i3c_gpio_write_reg(struct cdns_i3c_gpio *gpioc, u8 reg,
> + u8 val)
> +{
> + struct i3c_priv_xfer xfers[] = {
> + {
> + .len = sizeof(reg),
> + .data.out = ,
> + },
> + {
> + .len = sizeof(val),
> + .data.out = ,
> + },
> + };
> +
> + return i3c_device_do_priv_xfers(gpioc->i3cdev, xfers,
> + ARRAY_SIZE(xfers));
> +}
This is starting to resemble
drivers/base/regmap/regmap-i2c.c
Maybe we should very quickly add regmap-i3c.c as this
infrastructre has had a great positive effect on may kernel
subsystems.
> +static int cdns_i3c_gpio_get_direction(struct gpio_chip *g, unsigned offset)
> +{
> + struct cdns_i3c_gpio *gpioc = gpioc_to_cdns_gpioc(g);
> +
> + return gpioc->dir & BIT(offset);
I would:
return !!(gpioc->dir & BIT(offset));
So you clamp it to bit 0.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver
VSCSI server device, What is that acronym now, I get completely confused. > is presented to a designated > +management partition as a virtual device and is only presented when the > +system is not HMC managed. > +This communication device borrows aspects from both VSCSI and ILLAN devices Now there is ILLAN too. > +and is implemented using the CRQ and the RDMA interfaces. CRQ and RDMA. The RDMA I heard about, I wonder what CRQ is. At this point the document is referring to so much external a priori knowledge that I don't have that I don't understand anything at all. So if this document is meant as an introduction to the technology for newcomers, it's not working at all, unfortunately. If some specific domain knowledge is needed to read and understand the document, you need to state these prerequisites at the beginning of the document. Something like: "if you don't know a lot about virtualization already, then don't even bother trying to read this document". Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: > Jonathan Neuschäfer (8): > MAINTAINERS: GPIO: Add Documentation/driver-api/gpio/ > Documentation: driver-api: Move gpio.rst to gpio/index.rst > Documentation: gpio: Move introduction to driver-api > Documentation: gpio: Move driver documentation to driver-api > Documentation: gpio: Move legacy documentation to driver-api > Documentation: gpio: Move gpiod_* consumer documentation to driver-api > Documentation: gpio: Move GPIO mapping documentation to driver-api > Documentation: gpio: Move drivers-on-gpio.txt to driver-api I applied all 8 patches to devel for v4.17. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Move most GPIO documentation to driver-api/gpio/ and ReST
On Fri, Mar 9, 2018 at 12:40 AM, Jonathan Neuschäfer <j.neuschae...@gmx.net> wrote: > The aim of this patchset is to move the GPIO subsystem's documentation > under Documentation/driver-api/gpio/ such that it is picked up by Sphinx > and compiled into HTML. Awesome! > I moved everything except for sysfs.txt, because > this file describes the legacy sysfs ABI, and doesn't seem to serve much > (non-historical) purpose anymore. > > There are still some rough edges: > > * I think the API documentation (kernel-doc) should be moved out of > index.rst into more appropriate files. > * The headings are arguably wrong, because driver.rst, consumer.rst, > etc. use the "document title" style, even though they are part of the > GPIO chapter. But the resulting TOC tree is consistent, and I did not > want to change almost all headings. > * Some of the files could use more :c:func:`...` references and general > ReST polish. > > But I don't want to make this patchset too large. It's fine, we take it one step at a time. On Fri, Mar 09, 2018 at 10:41:20AM -0700, Jonathan Corbet wrote: > Anyway, I'm happy to take these through the docs tree or see them go via > GPIO; Linus, what's your preference? I might have some doc patches that could collide so I can take them. I take it there will be a v2? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/5] gpio: gpiolib: Add chardev support for maintaining GPIO values on reset
On Thu, Oct 26, 2017 at 2:05 AM, Andrew Jeffery <and...@aj.id.au> wrote: > I feel that taking this argument to its logical conclusion leads to > never exporting any GPIOs to userspace and doing everything in the > kernel. That is very much how I feel about things anyways. In a recent presentation: https://dflund.se/~triad/papers/GPIO-for-Engineers-and-Makers.pdf I had the following text: The Rules of Linux Userspace GPIO 1. You do not access GPIOs from userspace 2. YOU DO NOT ACCESS GPIOS FROM USERSPACE 3. Read Documentation/gpio/drivers-on-gpio.txt 4. Use the character device > If userspace has exported the GPIO and is managing its state, > then it can *already* cause very weird hardware behaviour if set wrong. > The fact that userspace is controlling the GPIO state and not the > kernel already says that the kernel doesn't know how to manage it, so > why not expose the option for userspace to set the persistence, given > that it should know what it's doing? People do need to access GPIOs from userspace for things like one-off makerspace projects, relays on factory lines, fire alarms, door openers etc etc. One-off projects is fine, the user likely has an idea about the whole system that is comprehensive. They use the random raspberry Pi (etc) development board for this. OK. When we are talking about adding GPIO in mass-market goods such as phones and tablets and laptops userspace GPIO access become more and more dubious. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset
On Fri, Oct 20, 2017 at 9:17 AM, Linus Walleij <linus.wall...@linaro.org> wrote: > On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <and...@aj.id.au> wrote: > >> GPIO state reset tolerance is implemented in gpiolib through the >> addition of a new pinconf parameter. With that, some renaming of helpers >> is done to clarify the scope of the already existing >> gpiochip_line_is_persistent(), as it's now ambiguous as to whether that >> means on suspend, reset or both. > > Isn't it most reasonable to say persistance covers both cases, reset > and/or sleep? This seems a bit like overdefined. I should also add: right now persistance is defined in negative terms, you can supply the flag "may lose value", which means the subsystem by default, and driver by default, will try to keep values persistent across sleep. Then it is possible to opt in for not doing so. (Usually to save power I think.) I think that especially for userspace use cases, saving power should not really be the concern, but correct me if I'm wrong. I am thinking of a box with a DC plug wired up to a factory line here. What we have in the Arizona driver is an opt-in where the DT can say "don't preserve the value this line during system sleep" i.e. "lay lose value" and we can extend that flag to mean "don't preserve this line during reset either" but by default assume that we should. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/5] gpio: gpiolib: Add sysfs support for maintaining GPIO values on reset
On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <and...@aj.id.au> wrote: > Expose a new 'maintain' sysfs attribute to control both suspend and > reset tolerance. > > Signed-off-by: Andrew Jeffery <and...@aj.id.au> NAK. You will find the actual ABI documentation in Documentation/ABI/obsolete/sysfs-gpio that's why. This is being phased out and should not be extended. Everyone should use the character device, especially for new functionality. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/5] gpio: gpiolib: Add chardev support for maintaining GPIO values on reset
I paged Bartosz and Michael on this, they are experts on the use cases for the character device and their opinions are likely more valuable than mine. On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <and...@aj.id.au> wrote: > Similar to devicetree support, add flags and mappings to expose reset > tolerance configuration through the chardev interface. > > Signed-off-by: Andrew Jeffery <and...@aj.id.au> (...) > +* Unconditionally configure reset tolerance, as it's possible > +* that the tolerance flag itself becomes tolerant to resets. > +* Thus it could remain set from a previous environment, but > +* the current environment may not expect it so. > +*/ > + ret = gpiod_set_reset_tolerant(desc, > + !!(lflags & > GPIOHANDLE_REQUEST_RESET_TOLERANT)); > + if (ret < 0) > + goto out_free_descs; First, as noted in the first patch, IMO we should just go for persistance, i.e. you want to flag to the system to keep the line persistent in any case, no matter if the system goes to sleep or resets. So the usecase is going to be a control system or similar, a makerspace project, an industrial product of some kind, driving GPIO from userspace. I don't see it as helpful to give userspace control over whether the line is persistent or not. It is more reasonable to assume persistance for userspace use cases, don't you think? Whether the system goes to sleep or the gpiochip resets should not make a door suddenly close or the lights in the christmas tree go out, right? I think if the gpiochip supports persistance of any kind, we should try to use it and not have userspace provide flags for that. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/5] gpio: gpiolib: Add OF support for maintaining GPIO values on reset
On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <and...@aj.id.au> wrote:
> @@ -32,6 +32,7 @@ enum of_gpio_flags {
> OF_GPIO_SINGLE_ENDED = 0x2,
> OF_GPIO_OPEN_DRAIN = 0x4,
> OF_GPIO_SLEEP_MAY_LOSE_VALUE = 0x8,
> + OF_GPIO_RESET_TOLERANT = 0x16,
Now you're mixing up decimal and hex.
Anyways, I do not think this is necessary.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/5] gpio: gpiolib: Add core support for maintaining GPIO values on reset
On Fri, Oct 20, 2017 at 5:37 AM, Andrew Jeffery <and...@aj.id.au> wrote: > GPIO state reset tolerance is implemented in gpiolib through the > addition of a new pinconf parameter. With that, some renaming of helpers > is done to clarify the scope of the already existing > gpiochip_line_is_persistent(), as it's now ambiguous as to whether that > means on suspend, reset or both. Isn't it most reasonable to say persistance covers both cases, reset and/or sleep? This seems a bit like overdefined. So can we say that is this flag is set, the hardware and driver should do its best to preserve the value across any system disruptions. We can change the wording of course, patches welcome for that. But do we really need to distinguish the cases of disruption and whether we cover up for them or not? I would say we can deal with that the day we have a system with two register bits (or similar) where you can select to preserve across sleep, reset, one or the other, AND there is also a usecase such that a user wants to preserve the value across reset but not suspend or vice versa. I suspect that will not happen. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] Documentation: fix ref to gpio.txt
On Thu, Oct 12, 2017 at 10:24 PM, Tom Saeger <tom.sae...@oracle.com> wrote: > Signed-off-by: Tom Saeger <tom.sae...@oracle.com> Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/3] gpio: mockup: use irq_sim
On Mon, Aug 14, 2017 at 1:20 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: > Shrink the driver by removing the code dealing with dummy interrupts > and replacing it with calls to the irq_sim API. > > Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl> > Acked-by: Jonathan Cameron <jonathan.came...@huawei.com> > Reviewed-by: Linus Walleij <linus.wall...@linaro.org> I applied this to the GPIO tree after pulling the infrastructure from Thomas branch. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] simulated interrupts
On Wed, Aug 16, 2017 at 4:44 PM, Thomas Gleixner <t...@linutronix.de> wrote: > I merged the irq part (1+2) into a separate branch, which can be consumed > by the gpio folks so the mockup driver patch can be merged as well. > >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/for-gpio Awesome, thanks Thomas. I pulled this into the GPIO devel branch. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/5] i3c: Add core I3C infrastructure
On Mon, Jul 31, 2017 at 6:24 PM, Boris Brezillon <boris.brezil...@free-electrons.com> wrote: > This infrastructure is not complete yet and will be extended over > time. I noticed the lack of pm_* from the core. This will be noticed very quickly since the means the problem seen in e.g. commit 04f59143b571 and the wakeup IRQ business will make it impossible to do power-efficient drivers until that is resolved. It'd be nice to have it to PM right from the start, and the I2C core has all the right infrastructure in place, so when this stabilize I'd say atleast it'd be *nice* if the PM business was added in the same kernel release that introduce this core infrastructure, even if it will be a separate patch. I.e. I consider that more of necessary bread and butter and less of nice to have topping on the cake. What I have seen that leaf vendors doing (i3c) device drivers do otherwise is complain "it is broken" and then they start to hack around it instead of helping out with the core. (I think you're well aware of that phenomenon.) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] gpio: mockup: use irq_sim
On Tue, Aug 1, 2017 at 4:50 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: > Shrink the driver by removing the code dealing with dummy interrupts > and replacing it with calls to the irq_sim API. > > Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> Tglx/Marc: feel free to merge this with the rest into the irqchip tree. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pinctrl: generic: update references to Documentation/pinctrl.txt
On Sun, Aug 6, 2017 at 4:00 PM, Ludovic Desroches
<ludovic.desroc...@o2linux.fr> wrote:
> Update deprecated references to Documentation/pinctrl.txt since it has been
> moved to Documentation/driver-api/pinctl.rst.
>
> Signed-off-by: Ludovic Desroches <ludovic.desroc...@o2linux.fr>
> Fixes: 5a9b73832e9e ("pinctrl.txt: move it to the driver-api book")
Patch applied for fixes.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] gpio: mockup: use irq_sim
On Wed, Jul 19, 2017 at 2:20 PM, Bartosz Golaszewski <b...@bgdev.pl> wrote: > Shrink the driver by removing the code dealing with dummy interrupts > and replacing it with calls to the irq_sim API. > > Signed-off-by: Bartosz Golaszewski <b...@bgdev.pl> Reviewed-by: Linus Walleij <linus.wall...@linaro.org> You can definately merge this along with the simulator into the IRQchip subsystem. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] simulated interrupts
On Wed, Jul 19, 2017 at 4:19 PM, Marc Zyngier <marc.zyng...@arm.com> wrote: > On a slightly tangential subject, there is another aspect that I thought > of implementing for a while, but always ended up just relying on a quick > hack: forcing the injection of an actual interrupt. A number of > interrupt controllers have the ability to make an interrupt pending, for > it to be handled as if a device had actually triggered it. This would be especially useful for a class of embedded systems that are woken up from deep sleep by an asynchronous interrupt controller. Usually GPIO(-ish) lines are armed and the system put to sleep, and when it comes up, the information of what line woke it up is there in a special register, but the actual (synchronous) interrupt line is no longer asserted or edge triggered, so an interrupt need to be inserted. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/29] pinctrl.txt: standardize document format
On Sat, Jun 17, 2017 at 5:03 PM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > Linus Walleij <linus.wall...@linaro.org> escreveu: >> Should the file be renamed pinctrl.rst now? > > If you just rename it, Sphinx will complain because it doesn't > belong to any index.rst file. As this is part of drivers/, I guess > the right thing is to add it to driver-api book. > > The enclosed patch should be doing it (it is based on linux-next). Hey it just applies, so I tossed in this patch too, thanks a lot! Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/10] pinctrl: sunxi: add support of R40 to A10 pinctrl driver
On Sat, May 27, 2017 at 12:23 PM, Icenowy Zheng <icen...@aosc.io> wrote: > R40 is said to be an upgrade of A20, and its pin configuration is also > similar to A20 (and thus similar to A10). > > Add support for R40 to the A10 pinctrl driver. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> Since I applied patches 2-5 you only need to resend from this point for pin control. Please send pin control patches separately from the rest of the series if you can, and rebase on my "devel" branch, so I don't have to sift throgh so much patches to find what I need to apply and what I can ignore. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] dt-bindings: add compatible string for Allwinner R40 pinctrl
On Sat, May 27, 2017 at 12:23 PM, Icenowy Zheng <icen...@aosc.io> wrote: > Allwinner R40 has a pin controller like the ones in older Allwinner SoCs > (especially A20), and can use modified version of the A10/A20 pinctrl > driver. > > Add a compatible string for it. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > Acked-by: Rob Herring <r...@kernel.org> > --- > Changes in v3: > - Added Rob's ACK. Patch applied with Chen-Yu's review tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 04/10] pinctrl: sunxi: drop dedicated A20 driver
On Sat, May 27, 2017 at 12:23 PM, Icenowy Zheng <icen...@aosc.io> wrote: > As we added A20 support to A10 pinctrl driver, now we can delete the > dedicated A20 pinctrl driver, which is duplicated code. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Changes in v3: > - Only remove the A20 driver(A10 driver for A20 is enabled in > the previous commit now). Patch applied with Chen-Yu's review tag, and I also fixed up the Makefile by removing the rule for this file. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] pinctrl: sunxi: add A20 support to A10 driver
On Sat, May 27, 2017 at 12:23 PM, Icenowy Zheng <icen...@aosc.io> wrote: > As A20 is designed as a pin-compatible upgrade of A10, their pin > controller are very similar, and can share one driver. > > Add A20 support to the A10 driver. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Changes in v3: > - Enable A10 driver for A20 and disable A20 driver in this commit, in > order to prevent A10 driver from conflicting with A20 driver. Patch applied with Chen-Yu's review tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 02/10] pinctrl: sunxi: Add SoC ID definitions for A10, A20 and R40 SoCs
On Sat, May 27, 2017 at 12:23 PM, Icenowy Zheng <icen...@aosc.io> wrote: > Allwinner A10, A20 and R40 SoCs have similar GPIO layout. > > Add SoC definitions in pinctrl-sunxi.h, in order to merge A20 support > into A10 driver, and add R40 support into it. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> > --- > Changes in v3: > - Commit message change. Patch applied with Chen-Yu's review tag. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/29] pinctrl.txt: standardize document format
On Fri, May 19, 2017 at 3:25 AM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > Each text file under Documentation follows a different > format. Some doesn't even have titles! > > Change its representation to follow the adopted standard, > using ReST markups for it to be parseable by Sphinx. > > This document is almost following the standard stile. > > There are only two things to adjust on it: > > - promote the level of the document title; > - mark literal blocks as such. > > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com> I applied the patch fixing some of the indentation mistakes pointed out by Geert. Should the file be renamed pinctrl.rst now? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] Initial Allwinner R40 support
On Thu, May 4, 2017 at 3:49 PM, Icenowy Zheng <icen...@aosc.io> wrote: > This is the first non-RFC version of this patchset, which added basical > support including I2C, UART and MMC to the mainline Linux. > > The pinctrl driver of A20 is also merged into the one of A10 before > R40 support is added into the A10 driver. I'd be happy to merge the pinctrl parts as soon as you fixed the things pointed out during review. Include Rob's ACKs on the DT binding patches please. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 10/10] ARM: dts: sun8i: Add board dts file for Banana Pi M2 Ultra
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng <icen...@aosc.io> wrote:
> From: Chen-Yu Tsai <w...@csie.org>
>
> The Banana Pi M2 Ultra is an SBC based on the Allwinner R40 SoC. The
> form factor and position of various connectors, leds and buttons is
> similar to the Banana Pi M1+, Banana Pi M3, and is exactly the same
> as the latest Banana Pi M64.
>
> It features:
>
> - X-Powers AXP221s PMIC connected to i2c0
> - 2 GB DDR3 DRAM
> - 8 GB eMMC
> - micro SD card slot
> - DC power jack
> - HDMI output
> - MIPI DSI connector
> - 2x USB 2.0 hosts
> - 1x USB 2.0 OTG
> - gigabit ethernet with Realtek RTL8211E transceiver
> - WiFi/Bluetooth with AP6212 chip, with external antenna connector
> - SATA and power connectors for native SATA support
> - camera sensor connector
> - consumer IR receiver
> - audio out headphone jack
> - onboard microphone
> - red, green, and blue LEDs
> - debug UART pins
> - Li-Po battery connector
> - Raspberry Pi B+ compatible GPIO header
> - power, reset, and boot control buttons
>
> This patch adds a dts file that enables debug UART and MMC support.
>
> Signed-off-by: Chen-Yu Tsai <w...@csie.org>
> Signed-off-by: Icenowy Zheng <icen...@aosc.xyz>
Eric put a lot of time and effort into naming the GPIO lines on the
other Pi board.
So please follow the good example and name the GPIO lines on this board
like in the other rpi boards, should be something like:
{
gpio-line-names = "...", "...";
};
This is very helpful for users.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/10] pinctrl: sunxi: switch A20's pinctrl driver to use the A10 version
On Thu, May 4, 2017 at 3:50 PM, Icenowy Zheng <icen...@aosc.io> wrote: > As we added A20 support to A10 pinctrl driver, now we can delete the > dedicated A20 pinctrl driver, and enable A10 driver for A20. > > Signed-off-by: Icenowy Zheng <icen...@aosc.io> Looks all right to me but I'm waiting for Maxime's review on these patches. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] pinctrl: sunxi: add driver for V3s SoC
On Tue, Jan 3, 2017 at 4:16 PM, Icenowy Zheng <icen...@aosc.xyz> wrote: > V3s SoC features only a pin controller (for the lack of CPUs part). > > Add a driver for this controller. > > Signed-off-by: Icenowy Zheng <icen...@aosc.xyz> Patch applied with Maxime's ACK. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ABI: rtc-ab8500: fix rtc_calibration documentation
On Sat, Oct 29, 2016 at 12:10 PM, Mauro Carvalho Chehab <mche...@s-opensource.com> wrote: > The "What:" field at the ABI should describe the location of > the ABI, e. g. the position under a mounted sysfs. > > Fix it. > > Cc: Mark Godfrey <mark.godf...@stericsson.com> > Cc: Linus Walleij <linus.wall...@linaro.org> > Cc: Alessandro Zummo <a.zu...@towertech.it> > Cc: Alexandre Belloni <alexandre.bell...@free-electrons.com> > Cc: linux-arm-ker...@lists.infradead.org > Cc: rtc-li...@googlegroups.com > Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com> Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"
On Mon, Oct 3, 2016 at 10:45 AM, Pavel Machek <pa...@ucw.cz> wrote: > Using "->" to indicate range is not too common, switch to ".." > > Signed-off-by: Pavel Machek <pa...@ucw.cz> You sent this patch to me... resend it to the regulator maintainer. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/board.txt: point to gpiod_set_value
On Mon, Oct 3, 2016 at 10:43 AM, Pavel Machek <pa...@ucw.cz> wrote: > gpiod_set_value() is preffered interface these days, so add a > pointer. Also fix a missing ). > > Signed-off-by: Pavel Machek <pa...@ucw.cz> Patch applied with some tweaking. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] pinctrl.txt: Reflow/wrap paragraph describing GPIO interaction
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <and...@aj.id.au> wrote: > Signed-off-by: Andrew Jeffery <and...@aj.id.au> Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pinctrl.txt: Fix grammar in pinmux request list
On Fri, Jun 10, 2016 at 9:16 AM, Andrew Jeffery <and...@aj.id.au> wrote: > Signed-off-by: Andrew Jeffery <and...@aj.id.au> Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/20] mfd: stw481x: Use devm_mfd_add_devices() for mfd_device registration
On Tue, Apr 5, 2016 at 1:48 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote: > Use devm_mfd_add_devices() for mfd devices registration and get > rid of .remove callback to remove mfd devices. This is done > by managed device framework. > > Signed-off-by: Laxman Dewangan <ldewan...@nvidia.com> > CC: Linus Walleij <linus.wall...@linaro.org> Acked-by: Linus Walleij <linus.wall...@linaro.org> Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}
On Wed, Mar 9, 2016 at 3:23 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote: >> Pushed the change at: >> Branch "devm_pinctrl_register" of >> https://github.com/ldewangan/linux-upstream.git. >> >> Base repo is >> for-next of >> https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git >> >> >> If required, I can send the V2 version of list with acks. > > Let me know if I need to send full series (V2 with collected ack) again or > fine to pull it from above location. Please collect the ACKs on your branch and ask me to pull it after v4.6-rc1. No need to resend the patches. Unfortunately it arrived too late for the merge window, but hey: we got the devm gpiochip in for v4.6. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: gpio: board: fix GPIO_LOOKUP{,_IDX} documentation
On Thu, Feb 25, 2016 at 8:00 AM, Gabor Juhos <juh...@openwrt.org> wrote:
> The 'dev_id' parameter of the GPIO_LOOKUP{,_IDX} macros were removed by
> commit ad824783fb23 ("gpio: better lookup method for platform GPIOs").
>
> Update the documentation to reflect that.
>
> Signed-off-by: Gabor Juhos <juh...@openwrt.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/50] pinctrl: Add and use devm_ apis for pinctrl_{register, unregister}
On Wed, Feb 24, 2016 at 2:15 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote: > Add resource manageemnt APIs fro pinctrl_register() and pinctrl_unregister() > and use these new APIs on hw driver to reduce the error path code and > remove callback for driver. As you can probably guess I like this too, so wait a while, collect ACKs and send me a branch to pull for this too. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
On Tue, Feb 23, 2016 at 4:15 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote: > I have made the repo in git hub as > https://github.com/ldewangan/linux-upstream.git Awesome. > branch name is devm_gpiochip. > https://github.com/ldewangan/linux-upstream/tree/devm_gpiochip I've pulled this branch into my tree on a separate branch for testing. I pushed the tree to kernel.org so that the zeroday autobuilders can have a go at it. If everything goes well I plan to merge this for v4.6, then we can merge the changes in pin control and other subsystems for v4.7. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/61] gpio: Add and use devm_gpiochip_add_data()
On Mon, Feb 22, 2016 at 3:07 PM, Laxman Dewangan <ldewan...@nvidia.com> wrote: > Add resource management APIs for gpiochip_add_data() and > gpiochip_remove() and use these APIs from different HW drivers. > > This is based on discussion on patch to use the new APIs. > gpio: Add devm_ apis for gpio_chip_add and remove Awesome! Do you have a git I can just pull these off so I don't have to apply then all one-by-one? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: update the devices.txt documentation
Alan is no longer maintaining this list through the Linux assigned
numbers authority. Make it a collective document by referring to
"the maintainers" in plural throughout, and naming the chardev and
block layer maintainers in particular as parties of involvement.
Cut down and remove some sections that pertained to the process of
maintaining the list at lanana.org and contacting Alan directly.
Make it clear that this document, in the kernel, is the master
document.
Also move paragraphs around so as to emphasize dynamic major number
allocation.
Remove paragraph on 2.6 deprecation, that tag no longer appears
anywhere in the file.
Cc: Jonathan Corbet <cor...@lwn.net>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Alan Cox <a...@linux.intel.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Jens Axboe <ax...@kernel.dk>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
Greg I guess this can go through the drivercore tree?
---
CREDITS | 1 +
Documentation/devices.txt | 80 +++
2 files changed, 26 insertions(+), 55 deletions(-)
diff --git a/CREDITS b/CREDITS
index a3887b59b9f9..a9622329e336 100644
--- a/CREDITS
+++ b/CREDITS
@@ -768,6 +768,7 @@ D: Z85230 driver
D: Former security contact point (please use vendor-...@lst.de)
D: ex 2.2 maintainer
D: 2.1.x modular sound
+D: Assigned major/minor numbers maintainer at lanana.org
S: c/o Red Hat UK Ltd
S: Alexandra House
S: Alexandra Terrace
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index f1c441e085e9..2a4242be2fcd 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -1,20 +1,17 @@
- LINUX ALLOCATED DEVICES (2.6+ version)
-
-Maintained by Alan Cox <dev...@lanana.org>
-
- Last revised: 6th April 2009
+ LINUX ALLOCATED DEVICES (4.x+ version)
This list is the Linux Device List, the official registry of allocated
device numbers and /dev directory nodes for the Linux operating
system.
-The latest version of this list is available from
-http://www.lanana.org/docs/device-list/ or
-ftp://ftp.kernel.org/pub/linux/docs/device-list/. This version may be
-newer than the one distributed with the Linux kernel.
-
-The LaTeX version of this document is no longer maintained.
+The LaTeX version of this document is no longer maintained, nor is
+the document that used to reside at lanana.org. This version in the
+mainline Linux kernel is the master document. Updates shall be sent
+as patches to the kernel maintainers (see the SubmittingPatches document).
+Specifically explore the sections titled "CHAR and MISC DRIVERS", and
+"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers
+to involve for character and block devices.
This document is included by reference into the Filesystem Hierarchy
Standard (FHS). The FHS is available from http://www.pathname.com/fhs/.
@@ -23,60 +20,33 @@ Allocations marked (68k/Amiga) apply to Linux/68k on the
Amiga
platform only. Allocations marked (68k/Atari) apply to Linux/68k on
the Atari platform only.
-The symbol {2.6} means the allocation is obsolete and scheduled for
-removal once kernel version 2.6 (or equivalent) is released. Some of these
-allocations have already been removed.
-
-This document is in the public domain. The author requests, however,
+This document is in the public domain. The authors requests, however,
that semantically altered versions are not distributed without
-permission of the author, assuming the author can be contacted without
+permission of the authors, assuming the authors can be contacted without
an unreasonable effort.
-In particular, please don't sent patches for this list to Linus, at
-least not without contacting me first.
-
-I do not have any information about these devices beyond what appears
-on this list. Any such information requests will be deleted without
-reply.
-
DEVICE DRIVERS AUTHORS PLEASE READ THIS
-To have a major number allocated, or a minor number in situations
-where that applies (e.g. busmice), please contact me with the
-appropriate device information. Also, if you have additional
-information regarding any of the devices listed below, or if I have
-made a mistake, I would greatly appreciate a note.
-
-I do, however, make a few requests about the nature of your report.
-This is necessary for me to be able to keep this list up to date and
-correct in a timely manner. First of all, *please* send it to the
-correct address... <dev...@lanana.org>. I receive hundreds of email
-messages a day, so mail sent to other addresses may very well get lost
-in the avalanche. Please put in a descriptive subject, so I can find
-your mail again should I need to. Too many people send me email
-saying
