Re: [PATCH v7 0/6] gpio: Add GPIO Aggregator
gt; destroyed by writing to atribute files in sysfs.
> Sample session on the Renesas Koelsch development board:
>
> - Unbind LEDs from leds-gpio driver:
>
> echo leds > /sys/bus/platform/drivers/leds-gpio/unbind
>
> - Create aggregators:
>
> $ echo e6052000.gpio 19,20 \
> > /sys/bus/platform/drivers/gpio-aggregator/new_device
>
> gpio-aggregator gpio-aggregator.0: gpio 0 => gpio-953
> gpio-aggregator gpio-aggregator.0: gpio 1 => gpio-954
> gpiochip_find_base: found new base at 758
> gpio gpiochip12: (gpio-aggregator.0): added GPIO chardev (254:13)
> gpiochip_setup_dev: registered GPIOs 758 to 759 on device: gpiochip12
> (gpio-aggregator.0)
>
> $ echo e6052000.gpio 21 e605.gpio 20-22 \
> > /sys/bus/platform/drivers/gpio-aggregator/new_device
>
> gpio-aggregator gpio-aggregator.1: gpio 0 => gpio-955
> gpio-aggregator gpio-aggregator.1: gpio 1 => gpio-1012
> gpio-aggregator gpio-aggregator.1: gpio 2 => gpio-1013
> gpio-aggregator gpio-aggregator.1: gpio 3 => gpio-1014
> gpiochip_find_base: found new base at 754
> gpio gpiochip13: (gpio-aggregator.1): added GPIO chardev (254:13)
> gpiochip_setup_dev: registered GPIOs 754 to 757 on device: gpiochip13
> (gpio-aggregator.1)
>
> - Adjust permissions on /dev/gpiochip1[23] (optional)
>
> - Control LEDs:
>
> $ gpioset gpiochip12 0=0 1=1 # LED6 OFF, LED7 ON
> $ gpioset gpiochip12 0=1 1=0 # LED6 ON, LED7 OFF
> $ gpioset gpiochip13 0=1 # LED8 ON
> $ gpioset gpiochip13 0=0 # LED8 OFF
>
> - Destroy aggregators:
>
> $ echo gpio-aggregator.0 \
> > /sys/bus/platform/drivers/gpio-aggregator/delete_device
> $ echo gpio-aggregator.1 \
> > /sys/bus/platform/drivers/gpio-aggregator/delete_device
>
> To ease testing, I have pushed this series to the
> topic/gpio-aggregator-v7 branch of my renesas-drivers repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> Thanks!
>
> References:
> [1] "[PATCH QEMU v2 0/5] Add a GPIO backend"
>
> (https://lore.kernel.org/linux-gpio/20200423090118.11199-1-geert+rene...@glider.be/)
> [2] "[PATCH V4 2/2] gpio: inverter: document the inverter bindings"
>
> (https://lore.kernel.org/r/1561699236-18620-3-git-send-email-harish_kand...@mentor.com/)
> [3] "[PATCH v6 0/8] gpio: Add GPIO Aggregator"
>
> (https://lore.kernel.org/linux-doc/20200324135328.5796-1-geert+rene...@glider.be/)
> [4] "[PATCH v5 0/5] gpio: Add GPIO Aggregator"
>
> (https://lore.kernel.org/r/20200218151812.7816-1-geert+rene...@glider.be/)
> [5] "[PATCH v4 0/5] gpio: Add GPIO Aggregator"
>
> (https://lore.kernel.org/r/20200115181523.23556-1-geert+rene...@glider.be)
> [6] "[PATCH v3 0/7] gpio: Add GPIO Aggregator/Repeater"
>
> (https://lore.kernel.org/r/20191127084253.16356-1-geert+rene...@glider.be/)
> [7] "[PATCH/RFC v2 0/5] gpio: Add GPIO Aggregator Driver"
>
> (https://lore.kernel.org/r/20190911143858.13024-1-geert+rene...@glider.be/)
> [8] "[PATCH RFC] gpio: Add Virtual Aggregator GPIO Driver"
>
> (https://lore.kernel.org/r/20190705160536.12047-1-geert+rene...@glider.be/)
> [9] "[PATCH QEMU POC] Add a GPIO backend"
>
> (https://lore.kernel.org/r/20181003152521.23144-1-geert+rene...@glider.be/)
> [10] "Getting To Blinky: Virt Edition / Making device pass-through
>work on embedded ARM"
> (https://fosdem.org/2019/schedule/event/vai_getting_to_blinky/)
>
> Geert Uytterhoeven (6):
> i2c: i801: Use GPIO_LOOKUP() helper macro
> mfd: sm501: Use GPIO_LOOKUP_IDX() helper macro
> gpiolib: Add support for GPIO lookup by line name
> gpio: Add GPIO Aggregator
> docs: gpio: Add GPIO Aggregator documentation
> MAINTAINERS: Add GPIO Aggregator section
>
> .../admin-guide/gpio/gpio-aggregator.rst | 111
> Documentation/admin-guide/gpio/index.rst | 1 +
> Documentation/driver-api/gpio/board.rst | 15 +-
> MAINTAINERS | 7 +
> drivers/gpio/Kconfig | 12 +
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-aggregator.c| 568 ++
> drivers/gpio/gpiolib.c| 22 +-
> drivers/i2c/busses/i2c-i801.c | 6 +-
> drivers/mfd/sm501.c | 24 +-
> include/linux/gpio/machine.h | 17 +-
> 11 files changed, 748 insertions(+), 36 deletions(-)
> create mode 100644 Documentation/admin-guide/gpio/gpio-aggregator.rst
> create mode 100644 drivers/gpio/gpio-aggregator.c
>
> --
> 2.17.1
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v7 0/6] gpio: Add GPIO Aggregator
On Wed, May 20, 2020 at 3:38 PM Geert Uytterhoeven wrote: > On Wed, May 20, 2020 at 2:14 PM Andy Shevchenko > wrote: > > On Mon, May 11, 2020 at 04:52:51PM +0200, Geert Uytterhoeven wrote: ... > > Sorry for late reply, recently noticed this nice idea. > > The comment I have is, please, can we reuse bitmap parse algorithm and > > syntax? > > We have too many different formats and parsers in the kernel and bitmap's > > one > > seems suitable here. > > Thank you, I wasn't aware of that. > > Which one do you mean? The documentation seems to be confusing, > and incomplete. > My first guess was bitmap_parse(), but that one assumes hex values? > And given it processes the unsigned long bitmap in u32 chunks, I guess > it doesn't work as expected on big-endian 64-bit? > > bitmap_parselist() looks more suitable, and the format seems to be > compatible with what's currently used, so it won't change ABI. > Is that the one you propose? Yes, sorry for the confusion. > > (Despite other small clean ups, like strstrip() use) > > Aka strim()? There are too many of them, to know all of them by heart ;-) The difference between them is __must_check flag. But yes. -- With Best Regards, Andy Shevchenko
Re: [PATCH v7 0/6] gpio: Add GPIO Aggregator
On Wed, May 20, 2020 at 3:40 PM Andy Shevchenko wrote: > On Wed, May 20, 2020 at 3:38 PM Geert Uytterhoeven > wrote: > > On Wed, May 20, 2020 at 2:14 PM Andy Shevchenko > > wrote: > > > On Mon, May 11, 2020 at 04:52:51PM +0200, Geert Uytterhoeven wrote: > > ... > > > > Sorry for late reply, recently noticed this nice idea. > > > The comment I have is, please, can we reuse bitmap parse algorithm and > > > syntax? > > > We have too many different formats and parsers in the kernel and bitmap's > > > one > > > seems suitable here. > > > > Thank you, I wasn't aware of that. > > > > Which one do you mean? The documentation seems to be confusing, > > and incomplete. > > My first guess was bitmap_parse(), but that one assumes hex values? > > And given it processes the unsigned long bitmap in u32 chunks, I guess > > it doesn't work as expected on big-endian 64-bit? > > > > bitmap_parselist() looks more suitable, and the format seems to be > > compatible with what's currently used, so it won't change ABI. What ABI? We didn't have a release with it, right? So, we are quite flexible for few more weeks to amend it. > > Is that the one you propose? > > Yes, sorry for the confusion. > > > > (Despite other small clean ups, like strstrip() use) > > > > Aka strim()? There are too many of them, to know all of them by heart ;-) > > The difference between them is __must_check flag. But yes. -- With Best Regards, Andy Shevchenko
Re: [Qemu-devel] [PATCH] headers: fix linux/mod_devicetable.h inclusions
On Mon, Jul 9, 2018 at 6:19 PM, Arnd Bergmann wrote:
> A couple of drivers produced build errors after the mod_devicetable.h
> header was split out from the platform_device one, e.g.
>
> drivers/media/platform/davinci/vpbe_osd.c:42:40: error: array type has
> incomplete element type 'struct platform_device_id'
> drivers/media/platform/davinci/vpbe_venc.c:42:40: error: array type has
> incomplete element type 'struct platform_device_id'
>
> This adds the inclusion where needed.
>
> Fixes: ac3167257b9f ("headers: separate linux/mod_devicetable.h from
> linux/platform_device.h")
> Signed-off-by: Arnd Bergmann
> drivers/platform/x86/intel_punit_ipc.c | 1 +
> --- a/drivers/platform/x86/intel_punit_ipc.c
> +++ b/drivers/platform/x86/intel_punit_ipc.c
> @@ -12,6 +12,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
Acked-by: Andy Shevchenko
for the above bits.
--
With Best Regards,
Andy Shevchenko
Re: [Qemu-devel] [PATCH v21 1/5] xbitmap: Introduce xbitmap
On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang wrote: > From: Matthew Wilcox > > The eXtensible Bitmap is a sparse bitmap representation which is > efficient for set bits which tend to cluster. It supports up to > 'unsigned long' worth of bits. > lib/xbitmap.c| 444 > +++ Please, split tests to a separate module. -- With Best Regards, Andy Shevchenko
Re: [Qemu-devel] [PATCH v21 1/5] xbitmap: Introduce xbitmap
On Fri, Feb 16, 2018 at 8:30 PM, Matthew Wilcox wrote: > On Fri, Feb 16, 2018 at 07:44:50PM +0200, Andy Shevchenko wrote: >> On Tue, Jan 9, 2018 at 1:10 PM, Wei Wang wrote: >> > From: Matthew Wilcox >> > >> > The eXtensible Bitmap is a sparse bitmap representation which is >> > efficient for set bits which tend to cluster. It supports up to >> > 'unsigned long' worth of bits. >> >> > lib/xbitmap.c| 444 >> > +++ >> >> Please, split tests to a separate module. > > Hah, I just did this two days ago! I didn't publish it yet, but I also made > it compile both in userspace and as a kernel module. > > It's the top two commits here: > > http://git.infradead.org/users/willy/linux-dax.git/shortlog/refs/heads/xarray-2018-02-12 > Thanks! > Note this is a complete rewrite compared to the version presented here; it > sits on top of the XArray and no longer has a preload interface. It has a > superset of the IDA functionality. Noted. Now, the question about test case. Why do you heavily use BUG_ON? Isn't resulting statistics enough? See how other lib/test_* modules do. -- With Best Regards, Andy Shevchenko
