Re: [PATCH 1/3] dt-bindings: net: renesas-ravb: Make stream buffer optional

[Rob Herring]

On Tue, Feb 06, 2018 at 02:05:52PM +0100, Geert Uytterhoeven wrote:
> The Stream Buffer for EtherAVB-IF (STBE) is an optional component, and
> is not present on all SoCs.
> 
> Document this in the DT bindings, including a list of SoCs that do have
> it.
> 
> Fixes: 785ec87483d1e24a ("ravb: document R8A77970 bindings")
> Fixes: f231c4178a655b09 ("dt-bindings: net: renesas-ravb: Add support for 
> R8A77995 RAVB")
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/devicetree/bindings/net/renesas,ravb.txt | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Kieran Bingham]

Hi Heiner,

On 09/02/18 17:59, Heiner Kallweit wrote:
> Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
>> Hi Wolfram,
>>
>> As part of my work looking at using i2c_new_secondary_device() to move 
>> address
>> mappings into the device tree, it has become evident that the return code of 
>> the
>> i2c_new_secondary_device() is obfuscated, and is simply a valid client - or 
>> NULL.
>>
>> This means that we must 'guess' as to whether the device failed due to a 
>> memory
>> allocation, or if the device address was already in use (perhaps a more 
>> common
>> failure).
>>
>> Because of this - I would like to see the return codes of
>> i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device()
>> support returning ERR_PTR()s rather than a client or NULL.
>>
>> These functions are used fairly extensively - thus it will be a fair bit of 
>> work
>> (or a good coccinelle script) - So I'd like to ask your opinion on the 
>> validity
>> of this task before I commence anything down that rabbit hole!
>>
>> Any comments? Pre-ack/nack? (from anyone?)
>>
> 
> This has been addressed as part of adding a devm_i2c_new_dummy().
> Related patches are in status "under review" since end of December.
> See also here:
> https://marc.info/?l=linux-i2c=151375074832371=2
> https://patchwork.ozlabs.org/patch/851268/
> 
> Maybe these patches cover already what you need.

Thankyou - I will take a look (albeit - next week now!)

--
Regards

Kieran

> 
> Rgds, Heiner
> 
>> --
>> Regards
>>
>> Kieran Bingham
>> .
>>
> 

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Heiner Kallweit]

Am 09.02.2018 um 11:01 schrieb Kieran Bingham:
> Hi Wolfram,
> 
> As part of my work looking at using i2c_new_secondary_device() to move address
> mappings into the device tree, it has become evident that the return code of 
> the
> i2c_new_secondary_device() is obfuscated, and is simply a valid client - or 
> NULL.
> 
> This means that we must 'guess' as to whether the device failed due to a 
> memory
> allocation, or if the device address was already in use (perhaps a more common
> failure).
> 
> Because of this - I would like to see the return codes of
> i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device()
> support returning ERR_PTR()s rather than a client or NULL.
> 
> These functions are used fairly extensively - thus it will be a fair bit of 
> work
> (or a good coccinelle script) - So I'd like to ask your opinion on the 
> validity
> of this task before I commence anything down that rabbit hole!
> 
> Any comments? Pre-ack/nack? (from anyone?)
> 

This has been addressed as part of adding a devm_i2c_new_dummy().
Related patches are in status "under review" since end of December.
See also here:
https://marc.info/?l=linux-i2c=151375074832371=2
https://patchwork.ozlabs.org/patch/851268/

Maybe these patches cover already what you need.

Rgds, Heiner

> --
> Regards
> 
> Kieran Bingham
> .
> 

[PATCH] ARM: shmobile: Enable RZA1 pin controller

[Jacopo Mondi]

Enable PINCTRL_RZA1 option in shmobile_defconfig

Signed-off-by: Jacopo Mondi 
---
Hi Simon,
  this fixes the issue you reported on Genmai when applying shmobile_defconfig.

---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 7b4fc01..12af8f4 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -120,6 +120,7 @@ CONFIG_SPI=y
 CONFIG_SPI_RSPI=y
 CONFIG_SPI_SH_MSIOF=y
 CONFIG_SPI_SH_HSPI=y
+CONFIG_PINCTRL_RZA1=y
 CONFIG_GPIO_EM=y
 CONFIG_GPIO_RCAR=y
 CONFIG_GPIO_PCF857X=y
--
2.7.4

Re: [PATCH/RFC 4/5] vfio: No-IOMMU mode support

[Alex Williamson]

On Fri, 9 Feb 2018 17:06:34 +0100
Geert Uytterhoeven  wrote:

> Hi Alex,
> 
> On Fri, Feb 9, 2018 at 4:50 PM, Alex Williamson
>  wrote:
> > On Fri,  9 Feb 2018 16:17:35 +0100
> > Geert Uytterhoeven  wrote:  
> >> From: Xiao Feng Ren 
> >>
> >> Add qemu support for the newly introduced VFIO No-IOMMU driver.
> >>
> >> We need to add special handling for:
> >> - Group character device is /dev/vfio/noiommu-$GROUP.
> >> - No-IOMMU does not rely on a memory listener.
> >> - No IOMMU will be set for its group, so no need to call
> >>   vfio_kvm_device_add_group.
> >>
> >> Signed-off-by: Xiao Feng Ren 
> >> [geert: Rebase]
> >> Signed-off-by: Geert Uytterhoeven 
> >> ---
> >>  hw/vfio/common.c  | 61 
> >> ++-
> >>  include/hw/vfio/vfio-common.h |  2 ++
> >>  2 files changed, 50 insertions(+), 13 deletions(-)  
> >
> > NAK.  I'm opposed to no-iommu support in QEMU in general, but accepting
> > vfio devices with no-iommu (which provide no DMA translation!!!)
> > transparently as if they might actually work like a regular vfio device
> > is absolutely unacceptable.  Without DMA translation and isolation, you
> > might want to think about another interface, I'm not keen on the idea  
> 
> What if the device cannot do DMA?
> 
> There are other devices that cannot do DMA, but that can be useful to
> access from a guest in an embedded system.
> E.g. smart ADC monitor blocks that monitor and average several ADCs in an
> automotive environment (drivers/iio/adc/rcar-gyroadc.c).
> 
> Should all such devices be paravirtualized?

How do we know that a device is not capable of DMA?  The moment we add
no-iommu support generically to QEMU, I get to deal with a swarm of
people trying to use it to assign DMA capable PCI devices to VMs and
failing miserably.  We added no-iommu support because the UIO PCI driver
was under pressure to add support for MSI/X interrupts and we figured
we could at least taint the kernel an give people a path to a more
secure setup with an IOMMU by allowing use of the vfio device
interface.  For PCI, this makes some sense because PCI has architected
interrupts and config space and standard layouts.  What's the value of
vfio over UIO for ad-hoc, non-DMA platform devices?  UIO is intended for
non-DMA devices.  vfio is intended for IOMMU protected, DMA capable
devices.  vfio no-IOMMU is a band-aide that hopefully goes away
eventually.

> > of corrupting vfio support in order to blink some LEDs.  Thanks,  
> 
> This GPIO+LED prototype is just a proof-of-concept. There's no plan to
> upstream it.

If vfio with no-IOMMU is to be used, it must not enable users to
casually assign DMA capable devices.  Certainly any PCI/e device needs
to be assumed to be DMA capable.  I don't know how you tell with
platform devices since there's no standard interface.  Thanks,

Alex

[GIT PULL FOR renesas-drivers] vsp1/vga-performance-fix

[Kieran Bingham]

Hi Geert,

Please consider including this fix for the VSP1 in renesas-drivers.

--
Regards

Kieran

The following changes since commit d8a5b80568a9cb66810e75b182018e9edb68e8ff:

  Linux 4.15 (2018-01-28 13:20:33 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git 
vsp1/vga-performance-fix

for you to fetch changes up to e0c81de98739197b6fda7ba65fe4f17c7a03c384:

  v4l: vsp1: Fix header display list status check in continuous mode 
(2018-02-09 15:57:49 +)


Kieran Bingham (1):
  v4l: vsp1: Fix header display list status check in continuous mode

 drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [PATCH/RFC 4/5] vfio: No-IOMMU mode support

[Geert Uytterhoeven]

Hi Alex,

On Fri, Feb 9, 2018 at 4:50 PM, Alex Williamson
 wrote:
> On Fri,  9 Feb 2018 16:17:35 +0100
> Geert Uytterhoeven  wrote:
>> From: Xiao Feng Ren 
>>
>> Add qemu support for the newly introduced VFIO No-IOMMU driver.
>>
>> We need to add special handling for:
>> - Group character device is /dev/vfio/noiommu-$GROUP.
>> - No-IOMMU does not rely on a memory listener.
>> - No IOMMU will be set for its group, so no need to call
>>   vfio_kvm_device_add_group.
>>
>> Signed-off-by: Xiao Feng Ren 
>> [geert: Rebase]
>> Signed-off-by: Geert Uytterhoeven 
>> ---
>>  hw/vfio/common.c  | 61 
>> ++-
>>  include/hw/vfio/vfio-common.h |  2 ++
>>  2 files changed, 50 insertions(+), 13 deletions(-)
>
> NAK.  I'm opposed to no-iommu support in QEMU in general, but accepting
> vfio devices with no-iommu (which provide no DMA translation!!!)
> transparently as if they might actually work like a regular vfio device
> is absolutely unacceptable.  Without DMA translation and isolation, you
> might want to think about another interface, I'm not keen on the idea

What if the device cannot do DMA?

There are other devices that cannot do DMA, but that can be useful to
access from a guest in an embedded system.
E.g. smart ADC monitor blocks that monitor and average several ADCs in an
automotive environment (drivers/iio/adc/rcar-gyroadc.c).

Should all such devices be paravirtualized?

> of corrupting vfio support in order to blink some LEDs.  Thanks,

This GPIO+LED prototype is just a proof-of-concept. There's no plan to
upstream it.

Thanks!

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

Re: [PATCH v5 2/6] clk: renesas: rcar-gen3: Add Z2 clock divider support

[Geert Uytterhoeven]

On Mon, Jan 29, 2018 at 7:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z2 clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

I.e. will queue in clk-renesas-for-v4.17.

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

Re: [PATCH v5 1/6] clk: renesas: rcar-gen3: Add Z clock divider support

[Geert Uytterhoeven]

On Mon, Jan 29, 2018 at 7:01 PM, Simon Horman
 wrote:
> From: Takeshi Kihara 
>
> This patch adds Z clock divider support for R-Car Gen3 SoC.
>
> Signed-off-by: Takeshi Kihara 
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

I.e. will queue in clk-renesas-for-v4.17.

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

Re: [PATCH/RFC 4/5] vfio: No-IOMMU mode support

[Alex Williamson]

On Fri,  9 Feb 2018 16:17:35 +0100
Geert Uytterhoeven  wrote:

> From: Xiao Feng Ren 
> 
> Add qemu support for the newly introduced VFIO No-IOMMU driver.
> 
> We need to add special handling for:
> - Group character device is /dev/vfio/noiommu-$GROUP.
> - No-IOMMU does not rely on a memory listener.
> - No IOMMU will be set for its group, so no need to call
>   vfio_kvm_device_add_group.
> 
> Signed-off-by: Xiao Feng Ren 
> [geert: Rebase]
> Signed-off-by: Geert Uytterhoeven 
> ---
>  hw/vfio/common.c  | 61 
> ++-
>  include/hw/vfio/vfio-common.h |  2 ++
>  2 files changed, 50 insertions(+), 13 deletions(-)

NAK.  I'm opposed to no-iommu support in QEMU in general, but accepting
vfio devices with no-iommu (which provide no DMA translation!!!)
transparently as if they might actually work like a regular vfio device
is absolutely unacceptable.  Without DMA translation and isolation, you
might want to think about another interface, I'm not keen on the idea
of corrupting vfio support in order to blink some LEDs.  Thanks,

Alex

> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index f895e3c3359af779..2ee94a3304202a74 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -1019,6 +1019,33 @@ static int vfio_connect_container(VFIOGroup *group, 
> AddressSpace *as,
>  container->fd = fd;
>  QLIST_INIT(>giommu_list);
>  QLIST_INIT(>hostwin_list);
> +container->noiommu = group->noiommu;
> +
> +if (container->noiommu) {
> +ret = ioctl(group->fd, VFIO_GROUP_SET_CONTAINER, );
> +if (ret) {
> +error_report("vfio: failed to set group container: %m");
> +ret = -errno;
> +goto free_container_exit;
> +}
> +
> +ret = ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_NOIOMMU_IOMMU);
> +if (!ret) {
> +error_report("vfio: No available IOMMU models");
> +ret = -EINVAL;
> +goto free_container_exit;
> +}
> +
> +ret = ioctl(fd, VFIO_SET_IOMMU, VFIO_NOIOMMU_IOMMU);
> +if (ret) {
> +error_report("vfio: failed to set iommu for container: %m");
> +ret = -errno;
> +goto free_container_exit;
> +}
> +
> +goto listener_register;
> +}
> +
>  if (ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU) ||
>  ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1v2_IOMMU)) {
>  bool v2 = !!ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1v2_IOMMU);
> @@ -1151,15 +1178,16 @@ static int vfio_connect_container(VFIOGroup *group, 
> AddressSpace *as,
>  group->container = container;
>  QLIST_INSERT_HEAD(>group_list, group, container_next);
>  
> -container->listener = vfio_memory_listener;
> -
> -memory_listener_register(>listener, container->space->as);
> -
> -if (container->error) {
> -ret = container->error;
> -error_setg_errno(errp, -ret,
> - "memory listener initialization failed for 
> container");
> -goto listener_release_exit;
> +listener_register:
> +if (!container->noiommu) {
> +container->listener = vfio_memory_listener;
> +memory_listener_register(>listener, container->space->as);
> +if (container->error) {
> +ret = container->error;
> +error_setg_errno(errp, -ret,
> +"memory listener initialization failed for container");
> +goto listener_release_exit;
> +}
>  }
>  
>  container->initialized = true;
> @@ -1169,7 +1197,9 @@ listener_release_exit:
>  QLIST_REMOVE(group, container_next);
>  QLIST_REMOVE(container, next);
>  vfio_kvm_device_del_group(group);
> -vfio_listener_release(container);
> +if (!container->noiommu) {
> +vfio_listener_release(container);
> +}
>  
>  free_container_exit:
>  g_free(container);
> @@ -1195,7 +1225,7 @@ static void vfio_disconnect_container(VFIOGroup *group)
>   * since unset may destroy the backend container if it's the last
>   * group.
>   */
> -if (QLIST_EMPTY(>group_list)) {
> +if (QLIST_EMPTY(>group_list) && !container->noiommu) {
>  vfio_listener_release(container);
>  }
>  
> @@ -1249,8 +1279,13 @@ VFIOGroup *vfio_get_group(int groupid, AddressSpace 
> *as, Error **errp)
>  snprintf(path, sizeof(path), "/dev/vfio/%d", groupid);
>  group->fd = qemu_open(path, O_RDWR);
>  if (group->fd < 0) {
> -error_setg_errno(errp, errno, "failed to open %s", path);
> -goto free_group_exit;
> +snprintf(path, sizeof(path), "/dev/vfio/noiommu-%d", groupid);
> +group->fd = qemu_open(path, O_RDWR);
> +if (group->fd < 0) {
> +error_setg_errno(errp, errno, "failed to open %s", path);
> +goto free_group_exit;
> +}
> +group->noiommu = 1;
>  

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

[Peter Maydell]

On 9 February 2018 at 15:37, Geert Uytterhoeven  wrote:
> Hi Peter,
>
> On Fri, Feb 9, 2018 at 4:27 PM, Peter Maydell  
> wrote:
>> On 9 February 2018 at 15:17, Geert Uytterhoeven  
>> wrote:
>>> Allow the instantation of generic dynamic sysbus devices again, without
>>> the need to create a new device-specific vfio type.
>>>
>>> This is a partial revert of commit  6f2062b9758ebc64 ("hw/arm/virt:
>>> Allow only supported dynamic sysbus devices").
>>>
>>> Not-Yet-Signed-off-by: Geert Uytterhoeven 
>>> ---
>>>  hw/arm/virt.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>> index b334c82edae9fb1f..fa83784fc08ed076 100644
>>> --- a/hw/arm/virt.c
>>> +++ b/hw/arm/virt.c
>>> @@ -1596,6 +1596,7 @@ static void virt_machine_class_init(ObjectClass *oc, 
>>> void *data)
>>>  mc->max_cpus = 255;
>>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
>>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
>>> +machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
>>>  mc->block_default_type = IF_VIRTIO;
>>>  mc->no_cdrom = 1;
>>>  mc->pci_allow_0_address = true;
>>
>> This needs a lot of justification. Dynamic sysbus is not supposed
>> to be for plugging any random sysbus device in, it's for vfio,
>> which needs special casing anyway to work right. (Overall it's
>
> Sure. Is there a way to limit this to vfio devices?

That would be the code here which implements the whitelist of
"only allow this for the vfio devices which we have
support for mangling the device tree for and know will work".

>> a terrible hack -- in an ideal world all vfio would use pci
>> or another probeable bus.)
>
> What about vfio-platform, which is my use case?
> On DT-based systems, platform devices are described very well in DT (even
> better than what's provided by probing PCI IDs and BARs ;-)

The TYPE_VFIO_* devices in the whitelist all use DT, yes:
the code to handle creating/mangling the dt nodes for the
passed-through device is in hw/arm/sysbus-fdt.c.

thanks
-- PMM

Re: [PATCH 1/2] media: i2c: adv748x: Simplify regmap configuration

[Kieran Bingham]

Hi Niklas,

On 09/02/18 15:39, Niklas Söderlund wrote:
> Hi Kieran,
> 
> Thanks for your patch.
> 
> On 2018-02-07 17:34:45 +, Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> The ADV748x has identical map configurations for each register map. The
>> duplication of each map can be simplified using a helper macro such that
>> each map is represented on a single line.
>>
>> Define ADV748X_REGMAP_CONF for this purpose and un-define after it's
>> use.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/i2c/adv748x/adv748x-core.c | 111 
>> ++-
>>  1 file changed, 22 insertions(+), 89 deletions(-)
>>
>> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
>> b/drivers/media/i2c/adv748x/adv748x-core.c
>> index fd92c9e4b519..71c69b816db2 100644
>> --- a/drivers/media/i2c/adv748x/adv748x-core.c
>> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
>> @@ -35,98 +35,31 @@
>>   * Register manipulation
>>   */
>>  
>> -static const struct regmap_config adv748x_regmap_cnf[] = {
>> -{
>> -.name   = "io",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "dpll",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "cp",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "hdmi",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "edid",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "repeater",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "infoframe",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "cec",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "sdp",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -
>> -{
>> -.name   = "txb",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> -
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> -{
>> -.name   = "txa",
>> -.reg_bits   = 8,
>> -.val_bits   = 8,
>> +#define ADV748X_REGMAP_CONF(n) \
>> +{ \
>> +.name = n, \
>> +.reg_bits = 8, \
>> +.val_bits = 8, \
>> +.max_register = 0xff, \
>> +.cache_type = REGCACHE_NONE, \
>> +}
>>  
>> -.max_register   = 0xff,
>> -.cache_type = REGCACHE_NONE,
>> -},
>> +static const struct regmap_config adv748x_regmap_cnf[] = {
>> +ADV748X_REGMAP_CONF("io"),
>> +ADV748X_REGMAP_CONF("dpll"),
>> +ADV748X_REGMAP_CONF("cp"),
>> +ADV748X_REGMAP_CONF("hdmi"),
>> +ADV748X_REGMAP_CONF("edid"),
>> +ADV748X_REGMAP_CONF("repeater"),
>> +ADV748X_REGMAP_CONF("infoframe"),
>> +ADV748X_REGMAP_CONF("cec"),
>> +ADV748X_REGMAP_CONF("sdp"),
>> +ADV748X_REGMAP_CONF("txa"),
>> +ADV748X_REGMAP_CONF("txb"),
>>  };
>>  
>> +#undef ADV748X_REGMAP_CONF
>> +
> 
> Why is this macro undefined here? It have a rather limited scope as it's 
> only local to this C file and it have a good prefix of ADV748X_ so 
> conflicts are highly unlikely. Is there 

Re: [PATCH 2/2] media: i2c: adv748x: Add missing CBUS page.

[Niklas Söderlund]

Hi Kieran,

Thanks for your patch,

On 2018-02-07 17:34:46 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The ADV748x has 12 pages mapped onto I2C addresses.
> 
> In the existing implementation only 11 are mapped correctly in the page
> enumerations, which causes an off-by-one fault on pages above the
> infoframe definition due to a missing 'CBUS' page.
> 
> This causes the address for the CEC, SDP, TXA, and TXB to be incorrectly
> programmed during the iterations in adv748x_initialise_clients().
> 
> Until now this has gone un-noticed due to the fact that following the
> creation of the clients - the device is reset and the addresses are
> reprogrammed in manually by the call to "adv748x_write_regs(state,
> adv748x_set_slave_address);"
> 
> As part of moving to dynamic i2c address allocations repair this by
> providing the missing CBUS page definition.
> 
> Signed-off-by: Kieran Bingham 

I would drop the '.' from the subject line, with that fixed:

Reviewed-by: Niklas Söderlund 

> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 3 +++
>  drivers/media/i2c/adv748x/adv748x.h  | 2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 71c69b816db2..6d62b817ed00 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -52,6 +52,7 @@ static const struct regmap_config adv748x_regmap_cnf[] = {
>   ADV748X_REGMAP_CONF("edid"),
>   ADV748X_REGMAP_CONF("repeater"),
>   ADV748X_REGMAP_CONF("infoframe"),
> + ADV748X_REGMAP_CONF("cbus"),
>   ADV748X_REGMAP_CONF("cec"),
>   ADV748X_REGMAP_CONF("sdp"),
>   ADV748X_REGMAP_CONF("txa"),
> @@ -91,6 +92,7 @@ static int adv748x_i2c_addresses[ADV748X_PAGE_MAX] = {
>   ADV748X_I2C_EDID,
>   ADV748X_I2C_REPEATER,
>   ADV748X_I2C_INFOFRAME,
> + ADV748X_I2C_CBUS,
>   ADV748X_I2C_CEC,
>   ADV748X_I2C_SDP,
>   ADV748X_I2C_TXB,
> @@ -354,6 +356,7 @@ static const struct adv748x_reg_value 
> adv748x_set_slave_address[] = {
>   {ADV748X_PAGE_IO, 0xf6, ADV748X_I2C_EDID << 1},
>   {ADV748X_PAGE_IO, 0xf7, ADV748X_I2C_REPEATER << 1},
>   {ADV748X_PAGE_IO, 0xf8, ADV748X_I2C_INFOFRAME << 1},
> + {ADV748X_PAGE_IO, 0xf9, ADV748X_I2C_CBUS << 1},
>   {ADV748X_PAGE_IO, 0xfa, ADV748X_I2C_CEC << 1},
>   {ADV748X_PAGE_IO, 0xfb, ADV748X_I2C_SDP << 1},
>   {ADV748X_PAGE_IO, 0xfc, ADV748X_I2C_TXB << 1},
> diff --git a/drivers/media/i2c/adv748x/adv748x.h 
> b/drivers/media/i2c/adv748x/adv748x.h
> index 6789e2f3bc8c..725662edc4b8 100644
> --- a/drivers/media/i2c/adv748x/adv748x.h
> +++ b/drivers/media/i2c/adv748x/adv748x.h
> @@ -35,6 +35,7 @@
>  #define ADV748X_I2C_EDID 0x36/* EDID Map */
>  #define ADV748X_I2C_REPEATER 0x32/* HDMI RX Repeater Map */
>  #define ADV748X_I2C_INFOFRAME0x31/* HDMI RX InfoFrame 
> Map */
> +#define ADV748X_I2C_CBUS 0x30/* CBUS MHL Map */
>  #define ADV748X_I2C_CEC  0x41/* CEC Map */
>  #define ADV748X_I2C_SDP  0x79/* SDP Map */
>  #define ADV748X_I2C_TXB  0x48/* CSI-TXB Map */
> @@ -48,6 +49,7 @@ enum adv748x_page {
>   ADV748X_PAGE_EDID,
>   ADV748X_PAGE_REPEATER,
>   ADV748X_PAGE_INFOFRAME,
> + ADV748X_PAGE_CBUS,
>   ADV748X_PAGE_CEC,
>   ADV748X_PAGE_SDP,
>   ADV748X_PAGE_TXB,
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH 1/2] media: i2c: adv748x: Simplify regmap configuration

[Niklas Söderlund]

Hi Kieran,

Thanks for your patch.

On 2018-02-07 17:34:45 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The ADV748x has identical map configurations for each register map. The
> duplication of each map can be simplified using a helper macro such that
> each map is represented on a single line.
> 
> Define ADV748X_REGMAP_CONF for this purpose and un-define after it's
> use.
> 
> Signed-off-by: Kieran Bingham 
> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 111 
> ++-
>  1 file changed, 22 insertions(+), 89 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index fd92c9e4b519..71c69b816db2 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -35,98 +35,31 @@
>   * Register manipulation
>   */
>  
> -static const struct regmap_config adv748x_regmap_cnf[] = {
> - {
> - .name   = "io",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "dpll",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "cp",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "hdmi",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "edid",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "repeater",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "infoframe",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "cec",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "sdp",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> -
> - {
> - .name   = "txb",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> -
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> - {
> - .name   = "txa",
> - .reg_bits   = 8,
> - .val_bits   = 8,
> +#define ADV748X_REGMAP_CONF(n) \
> +{ \
> + .name = n, \
> + .reg_bits = 8, \
> + .val_bits = 8, \
> + .max_register = 0xff, \
> + .cache_type = REGCACHE_NONE, \
> +}
>  
> - .max_register   = 0xff,
> - .cache_type = REGCACHE_NONE,
> - },
> +static const struct regmap_config adv748x_regmap_cnf[] = {
> + ADV748X_REGMAP_CONF("io"),
> + ADV748X_REGMAP_CONF("dpll"),
> + ADV748X_REGMAP_CONF("cp"),
> + ADV748X_REGMAP_CONF("hdmi"),
> + ADV748X_REGMAP_CONF("edid"),
> + ADV748X_REGMAP_CONF("repeater"),
> + ADV748X_REGMAP_CONF("infoframe"),
> + ADV748X_REGMAP_CONF("cec"),
> + ADV748X_REGMAP_CONF("sdp"),
> + ADV748X_REGMAP_CONF("txa"),
> + ADV748X_REGMAP_CONF("txb"),
>  };
>  
> +#undef ADV748X_REGMAP_CONF
> +

Why is this macro undefined here? It have a rather limited scope as it's 
only local to this C file and it have a good prefix of ADV748X_ so 
conflicts are highly unlikely. Is there something I'm missing?

Is it really customary to undefine helper macros like this once they are 
used to populate 

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

[Geert Uytterhoeven]

Hi Peter,

On Fri, Feb 9, 2018 at 4:27 PM, Peter Maydell  wrote:
> On 9 February 2018 at 15:17, Geert Uytterhoeven  
> wrote:
>> Allow the instantation of generic dynamic sysbus devices again, without
>> the need to create a new device-specific vfio type.
>>
>> This is a partial revert of commit  6f2062b9758ebc64 ("hw/arm/virt:
>> Allow only supported dynamic sysbus devices").
>>
>> Not-Yet-Signed-off-by: Geert Uytterhoeven 
>> ---
>>  hw/arm/virt.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index b334c82edae9fb1f..fa83784fc08ed076 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -1596,6 +1596,7 @@ static void virt_machine_class_init(ObjectClass *oc, 
>> void *data)
>>  mc->max_cpus = 255;
>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
>>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
>> +machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
>>  mc->block_default_type = IF_VIRTIO;
>>  mc->no_cdrom = 1;
>>  mc->pci_allow_0_address = true;
>
> This needs a lot of justification. Dynamic sysbus is not supposed
> to be for plugging any random sysbus device in, it's for vfio,
> which needs special casing anyway to work right. (Overall it's

Sure. Is there a way to limit this to vfio devices?

> a terrible hack -- in an ideal world all vfio would use pci
> or another probeable bus.)

What about vfio-platform, which is my use case?
On DT-based systems, platform devices are described very well in DT (even
better than what's provided by probing PCI IDs and BARs ;-)

Thanks!

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

Re: [PATCH] media: i2c: adv748x: Fix cleanup jump on chip identification

[Niklas Söderlund]

Hi Kieran,

Thanks for your patch.

On 2018-02-07 21:11:35 +, Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> The error handling for the adv748x_identify_chip() call erroneously
> jumps to the err_cleanup_clients label before the clients have been
> established.
> 
> Correct this by jumping to the next (and correct) label in the cleanup
> code: err_cleanup_dt.
> 
> Fixes: 3e89586a64df ("media: i2c: adv748x: add adv748x driver")
> 
> Signed-off-by: Kieran Bingham 

Reviewed-by: Niklas Söderlund 

> ---
>  drivers/media/i2c/adv748x/adv748x-core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/i2c/adv748x/adv748x-core.c 
> b/drivers/media/i2c/adv748x/adv748x-core.c
> index 6d62b817ed00..6ccaad7e9eca 100644
> --- a/drivers/media/i2c/adv748x/adv748x-core.c
> +++ b/drivers/media/i2c/adv748x/adv748x-core.c
> @@ -651,7 +651,7 @@ static int adv748x_probe(struct i2c_client *client,
>   ret = adv748x_identify_chip(state);
>   if (ret) {
>   adv_err(state, "Failed to identify chip");
> - goto err_cleanup_clients;
> + goto err_cleanup_dt;
>   }
>  
>   /* Configure remaining pages as I2C clients with regmap access */
> -- 
> 2.7.4
> 

-- 
Regards,
Niklas Söderlund

Re: [PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

[Peter Maydell]

On 9 February 2018 at 15:17, Geert Uytterhoeven  wrote:
> Allow the instantation of generic dynamic sysbus devices again, without
> the need to create a new device-specific vfio type.
>
> This is a partial revert of commit  6f2062b9758ebc64 ("hw/arm/virt:
> Allow only supported dynamic sysbus devices").
>
> Not-Yet-Signed-off-by: Geert Uytterhoeven 
> ---
>  hw/arm/virt.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
> index b334c82edae9fb1f..fa83784fc08ed076 100644
> --- a/hw/arm/virt.c
> +++ b/hw/arm/virt.c
> @@ -1596,6 +1596,7 @@ static void virt_machine_class_init(ObjectClass *oc, 
> void *data)
>  mc->max_cpus = 255;
>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
>  machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
> +machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
>  mc->block_default_type = IF_VIRTIO;
>  mc->no_cdrom = 1;
>  mc->pci_allow_0_address = true;

This needs a lot of justification. Dynamic sysbus is not supposed
to be for plugging any random sysbus device in, it's for vfio,
which needs special casing anyway to work right. (Overall it's
a terrible hack -- in an ideal world all vfio would use pci
or another probeable bus.)

thanks
-- PMM

[PATCH/RFC 2/6] vfio: Ignore real IOMMUs if CONFIG_VFIO_NOIOMMU=y

[Geert Uytterhoeven]

Allow use of the No-IOMMU mode even if a real IOMMU is present.
This is useful in case the device is not part of an actual IOMMU group.

Not-Signed-off-by: Geert Uytterhoeven 
---
Question:
  - Some devices (e.g. rcar-gpio) don't use DMA, so why do they need an
IOMMU group?
  - Even devices using DMA may do so using a separate DMAC module,
pointed to by "dmas" DT properties (e.g. sh-sci), hence they may be
not part of an IOMMU group.
  - How to know which devices do DMA?
---
 drivers/vfio/vfio.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index 2bc3705a99bd2f1a..7736c3fbe468a3da 100644
--- a/drivers/vfio/vfio.c
+++ b/drivers/vfio/vfio.c
@@ -129,9 +129,13 @@ struct iommu_group *vfio_iommu_group_get(struct device 
*dev)
 * bus.  We set iommudata simply to be able to identify these groups
 * as special use and for reclamation later.
 */
-   if (group || !noiommu || iommu_present(dev->bus))
+   if (group || !noiommu)
return group;
 
+   if (iommu_present(dev->bus))
+   dev_warn(dev, "iommu present (%ps), ignoring\n",
+dev->bus->iommu_ops);
+
group = iommu_group_alloc();
if (IS_ERR(group))
return NULL;
-- 
2.7.4

[PATCH/RFC 3/5] hw/arm/virt: Allow dynamic sysbus devices again

[Geert Uytterhoeven]

Allow the instantation of generic dynamic sysbus devices again, without
the need to create a new device-specific vfio type.

This is a partial revert of commit  6f2062b9758ebc64 ("hw/arm/virt:
Allow only supported dynamic sysbus devices").

Not-Yet-Signed-off-by: Geert Uytterhoeven 
---
 hw/arm/virt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index b334c82edae9fb1f..fa83784fc08ed076 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -1596,6 +1596,7 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
 mc->max_cpus = 255;
 machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_CALXEDA_XGMAC);
 machine_class_allow_dynamic_sysbus_dev(mc, TYPE_VFIO_AMD_XGBE);
+machine_class_allow_dynamic_sysbus_dev(mc, TYPE_SYS_BUS_DEVICE);
 mc->block_default_type = IF_VIRTIO;
 mc->no_cdrom = 1;
 mc->pci_allow_0_address = true;
-- 
2.7.4

[PATCH/RFC 0/5] R-Car Gen3 GPIO Pass-Through Prototype (QEMU)

[Geert Uytterhoeven]

Hi all,

This RFC patch series is the QEMU side of a GPIO Pass-Through prototype
for Renesas R-Car platforms using vfio-platform.  Together with its
counterpart for Linux, it provides direct access from a QEMU+KVM guest
to a GPIO controller in an R-Car Gen3 SoC.  This allows the guest to
control the LEDs on a Renesas Salvator-X(S) board.

This patch series is not meant to be upstreamed as-is.  Indeed, for
various reasons (e.g. security, as the different GPIOs on the same GPIO
controller may control different parts of the system) access to GPIOs is
better not implemented using Device Pass-Through, but by
paravirtualization.  Yet, this is still a simple and valuable
proof-of-concept, which can serve as a basis for the future development
of Pass-Through support for more complex platform devices on R-Car Gen3
SoCs.

  - Patches 1-2 (submitted before by Eric Auger) make the vfio-platform
device non-abstract, incl. matching using a compatible string.
  - Patch 3 allows dynamic sysbus devices again, without needing to
create device-specific vfio types for each and every new device.
  - Patch 4 (submitted before by Xiao Feng Ren) adds support for the
VFIO No-IOMMU mode, which was added to Linux two years ago (in
v4.4).
  - Patch 5 adds code to instantiate device nodes for Renesas R-Car Gen3
GPIO controllers.

Several questions and TODOs are appended to the individual patches.

Please see https://elinux.org/R-Car/Virtualization/VFIO for full usage
instructions of this prototype.

Thanks for your comments!

Auger Eric (2):
  vfio/platform: make the vfio-platform device non abstract
  hw/arm/sysbus-fdt: Allow device matching with compat string

Geert Uytterhoeven (2):
  hw/arm/virt: Allow dynamic sysbus devices again
  hw/arm/sysbus-fdt: Enable rcar-gen3-gpio dynamic instatiation

Xiao Feng Ren (1):
  vfio: No-IOMMU mode support

 hw/arm/sysbus-fdt.c | 108 +++-
 hw/arm/virt.c   |   1 +
 hw/vfio/common.c|  61 ++-
 hw/vfio/platform.c  |  20 +++-
 include/hw/vfio/vfio-common.h   |   2 +
 include/hw/vfio/vfio-platform.h |   2 +
 6 files changed, 166 insertions(+), 28 deletions(-)

-- 
2.7.4

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

[PATCH/RFC 5/6] gpio: rcar: Add virtualization workarounds

[Geert Uytterhoeven]

Allow to enable the driver if virtualization is enabled.

Handle the absence of clocks and interrupts, to support guests that
don't provide these yet.

Not-Signed-off-by: Geert Uytterhoeven 
---
To be dropped once clocks and interrupts are supported on the guest.
---
 drivers/gpio/Kconfig |  2 +-
 drivers/gpio/gpio-rcar.c | 28 
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13b8e6..50eeaa3bb0749b84 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -386,7 +386,7 @@ config GPIO_PXA
 
 config GPIO_RCAR
tristate "Renesas R-Car GPIO"
-   depends on ARCH_RENESAS || COMPILE_TEST
+   depends on ARCH_RENESAS || VIRTIO_MMIO || COMPILE_TEST
select GPIOLIB_IRQCHIP
help
  Say yes here to support GPIO on Renesas R-Car SoCs.
diff --git a/drivers/gpio/gpio-rcar.c b/drivers/gpio/gpio-rcar.c
index e76de57dd617d7e2..bc205b7fbb30e892 100644
--- a/drivers/gpio/gpio-rcar.c
+++ b/drivers/gpio/gpio-rcar.c
@@ -442,22 +442,16 @@ static int gpio_rcar_probe(struct platform_device *pdev)
 
p->clk = devm_clk_get(dev, NULL);
if (IS_ERR(p->clk)) {
-   if (p->needs_clk) {
-   dev_err(dev, "unable to get clock\n");
-   ret = PTR_ERR(p->clk);
-   goto err0;
-   }
+   if (p->needs_clk)
+   dev_warn(dev, "missing clock, ignoring\n");
p->clk = NULL;
}
 
pm_runtime_enable(dev);
 
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
-   if (!irq) {
-   dev_err(dev, "missing IRQ\n");
-   ret = -EINVAL;
-   goto err0;
-   }
+   if (!irq)
+   dev_warn(dev, "missing IRQ, ignoring\n");
 
io = platform_get_resource(pdev, IORESOURCE_MEM, 0);
p->base = devm_ioremap_resource(dev, io);
@@ -502,12 +496,14 @@ static int gpio_rcar_probe(struct platform_device *pdev)
goto err1;
}
 
-   p->irq_parent = irq->start;
-   if (devm_request_irq(dev, irq->start, gpio_rcar_irq_handler,
-IRQF_SHARED, name, p)) {
-   dev_err(dev, "failed to request IRQ\n");
-   ret = -ENOENT;
-   goto err1;
+   if (irq) {
+   p->irq_parent = irq->start;
+   if (devm_request_irq(dev, irq->start, gpio_rcar_irq_handler,
+IRQF_SHARED, name, p)) {
+   dev_err(dev, "failed to request IRQ\n");
+   ret = -ENOENT;
+   goto err1;
+   }
}
 
dev_info(dev, "driving %d GPIOs\n", npins);
-- 
2.7.4

[PATCH/RFC 4/5] vfio: No-IOMMU mode support

[Geert Uytterhoeven]

From: Xiao Feng Ren 

Add qemu support for the newly introduced VFIO No-IOMMU driver.

We need to add special handling for:
- Group character device is /dev/vfio/noiommu-$GROUP.
- No-IOMMU does not rely on a memory listener.
- No IOMMU will be set for its group, so no need to call
  vfio_kvm_device_add_group.

Signed-off-by: Xiao Feng Ren 
[geert: Rebase]
Signed-off-by: Geert Uytterhoeven 
---
 hw/vfio/common.c  | 61 ++-
 include/hw/vfio/vfio-common.h |  2 ++
 2 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index f895e3c3359af779..2ee94a3304202a74 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -1019,6 +1019,33 @@ static int vfio_connect_container(VFIOGroup *group, 
AddressSpace *as,
 container->fd = fd;
 QLIST_INIT(>giommu_list);
 QLIST_INIT(>hostwin_list);
+container->noiommu = group->noiommu;
+
+if (container->noiommu) {
+ret = ioctl(group->fd, VFIO_GROUP_SET_CONTAINER, );
+if (ret) {
+error_report("vfio: failed to set group container: %m");
+ret = -errno;
+goto free_container_exit;
+}
+
+ret = ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_NOIOMMU_IOMMU);
+if (!ret) {
+error_report("vfio: No available IOMMU models");
+ret = -EINVAL;
+goto free_container_exit;
+}
+
+ret = ioctl(fd, VFIO_SET_IOMMU, VFIO_NOIOMMU_IOMMU);
+if (ret) {
+error_report("vfio: failed to set iommu for container: %m");
+ret = -errno;
+goto free_container_exit;
+}
+
+goto listener_register;
+}
+
 if (ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU) ||
 ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1v2_IOMMU)) {
 bool v2 = !!ioctl(fd, VFIO_CHECK_EXTENSION, VFIO_TYPE1v2_IOMMU);
@@ -1151,15 +1178,16 @@ static int vfio_connect_container(VFIOGroup *group, 
AddressSpace *as,
 group->container = container;
 QLIST_INSERT_HEAD(>group_list, group, container_next);
 
-container->listener = vfio_memory_listener;
-
-memory_listener_register(>listener, container->space->as);
-
-if (container->error) {
-ret = container->error;
-error_setg_errno(errp, -ret,
- "memory listener initialization failed for 
container");
-goto listener_release_exit;
+listener_register:
+if (!container->noiommu) {
+container->listener = vfio_memory_listener;
+memory_listener_register(>listener, container->space->as);
+if (container->error) {
+ret = container->error;
+error_setg_errno(errp, -ret,
+"memory listener initialization failed for container");
+goto listener_release_exit;
+}
 }
 
 container->initialized = true;
@@ -1169,7 +1197,9 @@ listener_release_exit:
 QLIST_REMOVE(group, container_next);
 QLIST_REMOVE(container, next);
 vfio_kvm_device_del_group(group);
-vfio_listener_release(container);
+if (!container->noiommu) {
+vfio_listener_release(container);
+}
 
 free_container_exit:
 g_free(container);
@@ -1195,7 +1225,7 @@ static void vfio_disconnect_container(VFIOGroup *group)
  * since unset may destroy the backend container if it's the last
  * group.
  */
-if (QLIST_EMPTY(>group_list)) {
+if (QLIST_EMPTY(>group_list) && !container->noiommu) {
 vfio_listener_release(container);
 }
 
@@ -1249,8 +1279,13 @@ VFIOGroup *vfio_get_group(int groupid, AddressSpace *as, 
Error **errp)
 snprintf(path, sizeof(path), "/dev/vfio/%d", groupid);
 group->fd = qemu_open(path, O_RDWR);
 if (group->fd < 0) {
-error_setg_errno(errp, errno, "failed to open %s", path);
-goto free_group_exit;
+snprintf(path, sizeof(path), "/dev/vfio/noiommu-%d", groupid);
+group->fd = qemu_open(path, O_RDWR);
+if (group->fd < 0) {
+error_setg_errno(errp, errno, "failed to open %s", path);
+goto free_group_exit;
+}
+group->noiommu = 1;
 }
 
 if (ioctl(group->fd, VFIO_GROUP_GET_STATUS, )) {
diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-common.h
index f3a2ac9fee02066f..aca2e33efb9b118c 100644
--- a/include/hw/vfio/vfio-common.h
+++ b/include/hw/vfio/vfio-common.h
@@ -77,6 +77,7 @@ struct VFIOGroup;
 typedef struct VFIOContainer {
 VFIOAddressSpace *space;
 int fd; /* /dev/vfio/vfio, empowered by the attached groups */
+bool noiommu;
 MemoryListener listener;
 MemoryListener prereg_listener;
 unsigned iommu_type;
@@ -136,6 +137,7 @@ struct VFIODeviceOps {
 typedef struct VFIOGroup {
 int fd;
 int groupid;
+bool noiommu;
 VFIOContainer *container;
 QLIST_HEAD(, VFIODevice) device_list;
 

[PATCH/RFC 5/5] hw/arm/sysbus-fdt: Enable rcar-gen3-gpio dynamic instantiation

[Geert Uytterhoeven]

Allow the instantiation of a Renesas R-Car Gen3 GPIO controller device
from the QEMU command line:

-device vfio-platform,host=,manufacturer=renesas,model=rcar-gen3-gpio
-device vfio-platform,sysfsdev=,manufacturer=renesas,model=rcar-gen3-gpio

A specialized device tree node is created for the guest, containing
compatible, reg, gpio-controller, and #gpio-cells properties.

Not-Yet-Signed-off-by: Geert Uytterhoeven 
---
Question:
  - Why do we need the manufacturer=foo,model=bar syntax? Can't this
just be extracted from the host DT?

TODO:
  - Copy properties from the host DT, as add_amd_xgbe_fdt_node() does,
  - Make this more generic?
---
 hw/arm/sysbus-fdt.c | 47 +++
 1 file changed, 47 insertions(+)

diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index c5d4fd5604c28118..428175f343d9f3b9 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -416,6 +416,52 @@ static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, void 
*opaque)
 return 0;
 }
 
+/**
+ * add_rcar_gpio_fdt_node
+ *
+ * Generates a simple node with following properties:
+ * compatible string, regs, #gpio-cells, gpio-controller
+ */
+static int add_rcar_gpio_fdt_node(SysBusDevice *sbdev, void *opaque)
+{
+PlatformBusFDTData *data = opaque;
+PlatformBusDevice *pbus = data->pbus;
+void *fdt = data->fdt;
+const char *parent_node = data->pbus_node_name;
+int compat_str_len, i;
+char *nodename;
+uint32_t *reg_attr;
+uint64_t mmio_base;
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+VFIODevice *vbasedev = >vbasedev;
+
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, 0);
+nodename = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
+   vbasedev->name, mmio_base);
+qemu_fdt_add_subnode(fdt, nodename);
+
+compat_str_len = strlen(vdev->compat) + 1;
+qemu_fdt_setprop(fdt, nodename, "compatible",
+  vdev->compat, compat_str_len);
+
+qemu_fdt_setprop(fdt, nodename, "gpio-controller", NULL, 0);
+qemu_fdt_setprop_cells(fdt, nodename, "#gpio-cells", 2);
+
+reg_attr = g_new(uint32_t, vbasedev->num_regions * 2);
+for (i = 0; i < vbasedev->num_regions; i++) {
+mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
+reg_attr[2 * i] = cpu_to_be32(mmio_base);
+reg_attr[2 * i + 1] = cpu_to_be32(
+memory_region_size(vdev->regions[i]->mem));
+}
+qemu_fdt_setprop(fdt, nodename, "reg", reg_attr,
+ vbasedev->num_regions * 2 * sizeof(uint32_t));
+
+g_free(reg_attr);
+g_free(nodename);
+return 0;
+}
+
 /* manufacturer/model matching */
 static bool vfio_platform_match(SysBusDevice *sbdev,
 const BindingEntry *entry)
@@ -454,6 +500,7 @@ static const BindingEntry bindings[] = {
 TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
 TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
 VFIO_PLATFORM_BINDING("amd", "xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
+VFIO_PLATFORM_BINDING("renesas", "rcar-gen3-gpio", add_rcar_gpio_fdt_node),
 #endif
 TYPE_BINDING("", NULL), /* last element */
 };
-- 
2.7.4

[PATCH/RFC 2/5] hw/arm/sysbus-fdt: Allow device matching with compat string

[Geert Uytterhoeven]

From: Auger Eric 

Up to now we have relied on the device type to identify a device tree
node creation function. Since we would like the VFIO-PLATFORM
device to be instantiable with different compatibility strings
we introduce the capability to specialize the node creation depending
on a manufacturer/model combo.

NodeCreationPair is renamed into BindingEntry. The struct is enhanced
with manufacturer, model and match_fn() fields. We introduce a new
matching function adapted to vfio-platform generic device.

>From now on, the AMD XGBE can be instantiated with either manner, ie:
-device vfio-amd-xgbe,host=e090.xgmac
or new option line:
-device 
vfio-platform,host=e090.xgmac,manufacturer=amd,model=xgbe-seattle-v1a

Signed-off-by: Eric Auger 
Signed-off-by: Geert Uytterhoeven 
---
 hw/arm/sysbus-fdt.c | 61 +
 1 file changed, 48 insertions(+), 13 deletions(-)

diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
index d68e3dcdbd260895..c5d4fd5604c28118 100644
--- a/hw/arm/sysbus-fdt.c
+++ b/hw/arm/sysbus-fdt.c
@@ -58,11 +58,14 @@ typedef struct PlatformBusFDTNotifierParams {
 ARMPlatformBusFDTParams *fdt_params;
 } PlatformBusFDTNotifierParams;
 
-/* struct that associates a device type name and a node creation function */
-typedef struct NodeCreationPair {
+/* struct that allows to match a device and create its FDT node */
+typedef struct BindingEntry {
 const char *typename;
-int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
-} NodeCreationPair;
+const char *manufacturer;
+const char *model;
+int  (*add_fn)(SysBusDevice *sbdev, void *opaque);
+bool (*match_fn)(SysBusDevice *sbdev, const struct BindingEntry *combo);
+} BindingEntry;
 
 /* helpers */
 
@@ -413,15 +416,46 @@ static int add_amd_xgbe_fdt_node(SysBusDevice *sbdev, 
void *opaque)
 return 0;
 }
 
+/* manufacturer/model matching */
+static bool vfio_platform_match(SysBusDevice *sbdev,
+const BindingEntry *entry)
+{
+VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
+
+if (strcmp(entry->model, vdev->model)) {
+return false;
+}
+
+if (entry->manufacturer) {
+if (!vdev->manufacturer) {
+return false;
+}
+return !strcmp(entry->manufacturer, vdev->manufacturer);
+}
+return true;
+}
+
+#define VFIO_PLATFORM_BINDING(manuf, model, add_fn) \
+{TYPE_VFIO_PLATFORM, (manuf), (model), (add_fn), vfio_platform_match}
+
 #endif /* CONFIG_LINUX */
 
-/* list of supported dynamic sysbus devices */
-static const NodeCreationPair add_fdt_node_functions[] = {
+/* Device type based matching */
+static bool type_match(SysBusDevice *sbdev, const BindingEntry *entry)
+{
+return !strcmp(object_get_typename(OBJECT(sbdev)), entry->typename);
+}
+
+#define TYPE_BINDING(type, add_fn) {(type), NULL, NULL, (add_fn), type_match}
+
+/* list of supported dynamic sysbus bindings */
+static const BindingEntry bindings[] = {
 #ifdef CONFIG_LINUX
-{TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node},
-{TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node},
+TYPE_BINDING(TYPE_VFIO_CALXEDA_XGMAC, add_calxeda_midway_xgmac_fdt_node),
+TYPE_BINDING(TYPE_VFIO_AMD_XGBE, add_amd_xgbe_fdt_node),
+VFIO_PLATFORM_BINDING("amd", "xgbe-seattle-v1a", add_amd_xgbe_fdt_node),
 #endif
-{"", NULL}, /* last element */
+TYPE_BINDING("", NULL), /* last element */
 };
 
 /* Generic Code */
@@ -440,10 +474,11 @@ static void add_fdt_node(SysBusDevice *sbdev, void 
*opaque)
 {
 int i, ret;
 
-for (i = 0; i < ARRAY_SIZE(add_fdt_node_functions); i++) {
-if (!strcmp(object_get_typename(OBJECT(sbdev)),
-add_fdt_node_functions[i].typename)) {
-ret = add_fdt_node_functions[i].add_fdt_node_fn(sbdev, opaque);
+for (i = 0; i < ARRAY_SIZE(bindings); i++) {
+const BindingEntry *iter = [i];
+
+if (iter->match_fn(sbdev, iter)) {
+ret = iter->add_fn(sbdev, opaque);
 assert(!ret);
 return;
 }
-- 
2.7.4

[PATCH/RFC 1/5] vfio/platform: make the vfio-platform device non abstract

[Geert Uytterhoeven]

From: Auger Eric 

Up to now the vfio-platform device has been abstract and could not be
instantiated. The integration of a new vfio platform device required
to create a dummy derived device which only set the compatibility
string.

Following the few vfio-platform device integration we have seen
the actual requested adaptation happens on device tree node creation
(sysbus-fdt).

So this patch removes the abstract setting and defines 2 new options,
manufacturer and model that are used to build a compatibility string.

This latter will be used to match the device tree node creation
function

sysbus-fdt does not support the instantiation of the vfio-platform
device yet.

Signed-off-by: Eric Auger 
[geert: Rebase, Set user_creatable=true]
Signed-off-by: Geert Uytterhoeven 
---
 hw/vfio/platform.c  | 20 ++--
 include/hw/vfio/vfio-platform.h |  2 ++
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/hw/vfio/platform.c b/hw/vfio/platform.c
index 0d4bc0aae8891435..32bed1974e23c569 100644
--- a/hw/vfio/platform.c
+++ b/hw/vfio/platform.c
@@ -637,7 +637,20 @@ static void vfio_platform_realize(DeviceState *dev, Error 
**errp)
 VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(dev);
 SysBusDevice *sbdev = SYS_BUS_DEVICE(dev);
 VFIODevice *vbasedev = >vbasedev;
-int i, ret;
+int i, ret = -EINVAL;
+
+if (!vdev->compat) {
+if (!vdev->model) {
+error_setg(errp, "no usable compatible string");
+goto out;
+}
+if (!vdev->manufacturer) {
+vdev->compat = g_strdup(vdev->model);
+} else {
+vdev->compat = g_strjoin(",", vdev->manufacturer,
+ vdev->model, NULL);
+}
+}
 
 vbasedev->type = VFIO_DEVICE_TYPE_PLATFORM;
 vbasedev->dev = dev;
@@ -681,6 +694,8 @@ static const VMStateDescription vfio_platform_vmstate = {
 static Property vfio_platform_dev_properties[] = {
 DEFINE_PROP_STRING("host", VFIOPlatformDevice, vbasedev.name),
 DEFINE_PROP_STRING("sysfsdev", VFIOPlatformDevice, vbasedev.sysfsdev),
+DEFINE_PROP_STRING("manufacturer", VFIOPlatformDevice, manufacturer),
+DEFINE_PROP_STRING("model", VFIOPlatformDevice, model),
 DEFINE_PROP_BOOL("x-no-mmap", VFIOPlatformDevice, vbasedev.no_mmap, false),
 DEFINE_PROP_UINT32("mmap-timeout-ms", VFIOPlatformDevice,
mmap_timeout, 1100),
@@ -699,6 +714,8 @@ static void vfio_platform_class_init(ObjectClass *klass, 
void *data)
 dc->desc = "VFIO-based platform device assignment";
 sbc->connect_irq_notifier = vfio_start_irqfd_injection;
 set_bit(DEVICE_CATEGORY_MISC, dc->categories);
+/* Supported by TYPE_VIRT_MACHINE */
+dc->user_creatable = true;
 }
 
 static const TypeInfo vfio_platform_dev_info = {
@@ -707,7 +724,6 @@ static const TypeInfo vfio_platform_dev_info = {
 .instance_size = sizeof(VFIOPlatformDevice),
 .class_init = vfio_platform_class_init,
 .class_size = sizeof(VFIOPlatformDeviceClass),
-.abstract   = true,
 };
 
 static void register_vfio_platform_dev_type(void)
diff --git a/include/hw/vfio/vfio-platform.h b/include/hw/vfio/vfio-platform.h
index 9baaa2db09b84f3e..31b9a9800f7d9d00 100644
--- a/include/hw/vfio/vfio-platform.h
+++ b/include/hw/vfio/vfio-platform.h
@@ -55,6 +55,8 @@ typedef struct VFIOPlatformDevice {
 /* queue of pending IRQs */
 QSIMPLEQ_HEAD(pending_intp_queue, VFIOINTp) pending_intp_queue;
 char *compat; /* compatibility string */
+char *manufacturer; /* manufacturer (1st part of the compatible property) 
*/
+char *model; /* model (2d part of the compatible property) */
 uint32_t mmap_timeout; /* delay to re-enable mmaps after interrupt */
 QEMUTimer *mmap_timer; /* allows fast-path resume after IRQ hit */
 QemuMutex intp_mutex; /* protect the intp_list IRQ state */
-- 
2.7.4

[PATCH/RFC 6/6] arm64: Add virt_defconfig

[Geert Uytterhoeven]

Add a simple defconfig for virtualized arm64 machines, based on an
OpenWRT config.  This expects "initramfs.cpio" to exist, which can be
extracted from e.g. an OpenWRT image using binwalk.

CONFIG_GPIO_RCAR is enabled for testing GPIO pass-through on R-Car Gen3.

Not-Signed-off-by: Geert Uytterhoeven 
---
Not intended for upstream merge.
---
 arch/arm64/configs/virt_defconfig | 722 ++
 1 file changed, 722 insertions(+)
 create mode 100644 arch/arm64/configs/virt_defconfig

diff --git a/arch/arm64/configs/virt_defconfig 
b/arch/arm64/configs/virt_defconfig
new file mode 100644
index ..4477d75d8e982b37
--- /dev/null
+++ b/arch/arm64/configs/virt_defconfig
@@ -0,0 +1,722 @@
+CONFIG_LOCALVERSION="-arm64-virt"
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+# CONFIG_CROSS_MEMORY_ATTACH is not set
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_BSD_PROCESS_ACCT_V3=y
+CONFIG_RCU_EXPERT=y
+CONFIG_RCU_FANOUT=32
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_RELAY=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_INITRAMFS_SOURCE="initramfs.cpio"
+# CONFIG_RD_GZIP is not set
+# CONFIG_RD_BZIP2 is not set
+# CONFIG_RD_LZMA is not set
+# CONFIG_RD_XZ is not set
+# CONFIG_RD_LZO is not set
+# CONFIG_RD_LZ4 is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_SYSFS_SYSCALL is not set
+# CONFIG_FHANDLE is not set
+# CONFIG_AIO is not set
+# CONFIG_ADVISE_SYSCALLS is not set
+CONFIG_BPF_SYSCALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_VM_EVENT_COUNTERS is not set
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_CC_STACKPROTECTOR_REGULAR=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_PARTITION_ADVANCED=y
+# CONFIG_IOSCHED_DEADLINE is not set
+# CONFIG_IOSCHED_CFQ is not set
+CONFIG_ARCH_VEXPRESS=y
+CONFIG_PCI=y
+# CONFIG_CAVIUM_ERRATUM_22375 is not set
+# CONFIG_CAVIUM_ERRATUM_23154 is not set
+CONFIG_NR_CPUS=4
+CONFIG_PREEMPT_VOLUNTARY=y
+CONFIG_HZ_100=y
+# CONFIG_COMPACTION is not set
+CONFIG_ZSMALLOC=m
+CONFIG_CMDLINE="console=ttyAMA0"
+# CONFIG_EFI is not set
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_COMPAT=y
+# CONFIG_SUSPEND is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=m
+CONFIG_NET_KEY=m
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_NET_IPIP=m
+CONFIG_NET_IPGRE_DEMUX=m
+CONFIG_NET_IPGRE=m
+CONFIG_NET_IPGRE_BROADCAST=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
+CONFIG_SYN_COOKIES=y
+CONFIG_NET_IPVTI=m
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_INET_XFRM_MODE_TRANSPORT=m
+CONFIG_INET_XFRM_MODE_TUNNEL=m
+CONFIG_INET_XFRM_MODE_BEET=m
+# CONFIG_INET_DIAG is not set
+CONFIG_TCP_CONG_ADVANCED=y
+# CONFIG_TCP_CONG_BIC is not set
+# CONFIG_TCP_CONG_WESTWOOD is not set
+# CONFIG_TCP_CONG_HTCP is not set
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_IPCOMP=m
+CONFIG_INET6_XFRM_MODE_TRANSPORT=m
+CONFIG_INET6_XFRM_MODE_TUNNEL=m
+CONFIG_INET6_XFRM_MODE_BEET=m
+CONFIG_IPV6_VTI=m
+CONFIG_IPV6_SIT=m
+CONFIG_IPV6_SIT_6RD=y
+CONFIG_IPV6_GRE=m
+CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_IPV6_SUBTREES=y
+CONFIG_IPV6_MROUTE=y
+CONFIG_NETFILTER=y
+CONFIG_BRIDGE_NETFILTER=y
+# CONFIG_NETFILTER_INGRESS is not set
+CONFIG_NF_CONNTRACK=m
+CONFIG_NF_CONNTRACK_ZONES=y
+CONFIG_NF_CONNTRACK_EVENTS=y
+# CONFIG_NF_CT_PROTO_DCCP is not set
+# CONFIG_NF_CT_PROTO_SCTP is not set
+# CONFIG_NF_CT_PROTO_UDPLITE is not set
+CONFIG_NF_CONNTRACK_AMANDA=m
+CONFIG_NF_CONNTRACK_FTP=m
+CONFIG_NF_CONNTRACK_H323=m
+CONFIG_NF_CONNTRACK_IRC=m
+CONFIG_NF_CONNTRACK_SNMP=m
+CONFIG_NF_CONNTRACK_PPTP=m
+CONFIG_NF_CONNTRACK_SIP=m
+CONFIG_NF_CONNTRACK_TFTP=m
+CONFIG_NF_CT_NETLINK=m
+CONFIG_NF_TABLES=m
+CONFIG_NF_TABLES_INET=m
+CONFIG_NFT_EXTHDR=m
+CONFIG_NFT_META=m
+CONFIG_NFT_CT=m
+CONFIG_NFT_COUNTER=m
+CONFIG_NFT_LOG=m
+CONFIG_NFT_LIMIT=m
+CONFIG_NFT_MASQ=m
+CONFIG_NFT_REDIR=m
+CONFIG_NFT_NAT=m
+CONFIG_NFT_REJECT=m
+CONFIG_NFT_HASH=m
+CONFIG_NETFILTER_XT_MARK=m
+CONFIG_NETFILTER_XT_CONNMARK=m
+CONFIG_NETFILTER_XT_SET=m
+CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
+CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
+CONFIG_NETFILTER_XT_TARGET_CT=m
+CONFIG_NETFILTER_XT_TARGET_DSCP=m
+CONFIG_NETFILTER_XT_TARGET_HL=m
+CONFIG_NETFILTER_XT_TARGET_LED=m
+CONFIG_NETFILTER_XT_TARGET_LOG=m
+CONFIG_NETFILTER_XT_TARGET_NFLOG=m
+CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
+CONFIG_NETFILTER_XT_TARGET_TPROXY=m
+CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
+CONFIG_NETFILTER_XT_MATCH_ADDRTYPE=m
+CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
+CONFIG_NETFILTER_XT_MATCH_COMMENT=m
+CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
+CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
+CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
+CONFIG_NETFILTER_XT_MATCH_DSCP=m
+CONFIG_NETFILTER_XT_MATCH_ECN=m
+CONFIG_NETFILTER_XT_MATCH_ESP=m
+CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
+CONFIG_NETFILTER_XT_MATCH_HELPER=m
+CONFIG_NETFILTER_XT_MATCH_HL=m

[PATCH/RFC 1/6] vfio: platform: Allow runtime override of reset_required

[Geert Uytterhoeven]

Currently reset_required can be configured using a module parameter.
But it cannot be overridden at runtime through sysfs, as the parameter
is read-only.

Make it writeable for root, as this is useful if vfio-platform is
builtin, so the following works:

echo 0 > /sys/module/vfio_platform/parameters/reset_required

Not-Signed-off-by: Geert Uytterhoeven 
---
TODO: Implement a vfio reset driver instead.
---
 drivers/vfio/platform/vfio_platform.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vfio/platform/vfio_platform.c 
b/drivers/vfio/platform/vfio_platform.c
index 6561751a1063ee29..ef89146deddcea80 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -24,7 +24,7 @@
 #define DRIVER_DESC "VFIO for platform devices - User Level meta-driver"
 
 static bool reset_required = true;
-module_param(reset_required, bool, 0444);
+module_param(reset_required, bool, 0644);
 MODULE_PARM_DESC(reset_required, "override reset requirement (default: 1)");
 
 /* probing devices from the linux platform bus */
-- 
2.7.4

[PATCH/RFC 0/6] R-Car Gen3 GPIO Pass-Through Prototype (Linux)

[Geert Uytterhoeven]

Hi all,

This RFC patch series is the Linux side of a GPIO Pass-Through prototype
for Renesas R-Car platforms using vfio-platform.  Together with its
counterpart for QEMU, it provides direct access from a QEMU+KVM guest to
a GPIO controller in an R-Car Gen3 SoC.  This allows the guest to
control the LEDs on a Renesas Salvator-X(S) board.

This patch series is not meant to be upstreamed as-is.  Indeed, for
various reasons (e.g. security, as the different GPIOs on the same GPIO
controller may control different parts of the system) access to GPIOs is
better not implemented using Device Pass-Through, but by
paravirtualization.  Yet, this is still a simple and valuable
proof-of-concept, which can serve as a basis for the future development
of Pass-Through support for more complex platform devices on R-Car Gen3
SoCs.

This patch series consists of two parts:

  1. Patches 1-4 are Linux host patches.

 They provide workarounds for missing virtualization platform
 support (vfio reset, IOMMU group, clock domain), and a defconfig
 update for testing.

 These allow a GPIO controller to be unbound from its host driver,
 and rebound to vfio-platform, for pass-through to a guest:

echo e6055400.gpio > /sys/bus/platform/drivers/gpio_rcar/unbind
echo vfio-platform > \
/sys/bus/platform/devices/e6055400.gpio/driver_override
echo e6055400.gpio > /sys/bus/platform/drivers/vfio-platform/bind

  2. Patches 5-6 are Linux guest patches.

 They provide workarounds for missing pass-through support (clock,
 interrupt), and a guest defconfig for testing.

 These allow the gpio-rcar driver to bind to a pass-through GPIO
 device, and thus control the LEDs from the guest.

Several questions and TODOs are appended to the individual patches.

Please see https://elinux.org/R-Car/Virtualization/VFIO for full usage
instructions of this prototype.

Thanks for your comments!

Geert Uytterhoeven (6):
  vfio: platform: Allow runtime override of reset_required
  vfio: Ignore real IOMMUs if CONFIG_VFIO_NOIOMMU=y
  clk: renesas: r8a7795: Mark the GPIO6 clock critical
  arm64: renesas_defconfig: Enable VFIO_PLATFORM and VFIO_NOIOMMU
  gpio: rcar: Add virtualization workarounds
  arm64: Add virt_defconfig

 arch/arm64/configs/renesas_defconfig   |   2 +
 arch/arm64/configs/virt_defconfig  | 722 +
 drivers/clk/renesas/r8a7795-cpg-mssr.c |   1 +
 drivers/gpio/Kconfig   |   2 +-
 drivers/gpio/gpio-rcar.c   |  28 +-
 drivers/vfio/platform/vfio_platform.c  |   2 +-
 drivers/vfio/vfio.c|   6 +-
 7 files changed, 744 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm64/configs/virt_defconfig

-- 
2.7.4

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

[PATCH/RFC 3/6] clk: renesas: r8a7795: Mark the GPIO6 clock critical

[Geert Uytterhoeven]

The GPIO6 block will be exported to a guest.  As long as the guest won't
manage its module clock, it must be kept running by the host.

Not-Signed-off-by: Geert Uytterhoeven 
---
TODO: Find a way to manage module clocks using PM Domains and Runtime
  PM on the guest.
---
 drivers/clk/renesas/r8a7795-cpg-mssr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c 
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index b1d9f48eae9e6ad4..6fbfd5973a889b7d 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -271,6 +271,7 @@ static struct mssr_mod_clk r8a7795_mod_clks[] __initdata = {
 
 static const unsigned int r8a7795_crit_mod_clks[] __initconst = {
MOD_CLK_ID(408),/* INTC-AP (GIC) */
+   MOD_CLK_ID(906),/* GPIO6 */
 };
 
 
-- 
2.7.4

[PATCH/RFC 4/6] arm64: renesas_defconfig: Enable VFIO_PLATFORM and VFIO_NOIOMMU

[Geert Uytterhoeven]

Enable VFIO_PLATFORM for platform device pass-through.
Enable VFIO_NOIOMMU for devices not part of an IOMMU group.

Not-Signed-off-by: Geert Uytterhoeven 
---
Not intended for upstream merge.
---
 arch/arm64/configs/renesas_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/configs/renesas_defconfig 
b/arch/arm64/configs/renesas_defconfig
index 386211464efa4885..959aa9de8792ae2d 100644
--- a/arch/arm64/configs/renesas_defconfig
+++ b/arch/arm64/configs/renesas_defconfig
@@ -259,7 +259,9 @@ CONFIG_DMADEVICES=y
 CONFIG_RCAR_DMAC=y
 CONFIG_RENESAS_USB_DMAC=y
 CONFIG_VFIO=y
+CONFIG_VFIO_NOIOMMU=y
 CONFIG_VFIO_PCI=y
+CONFIG_VFIO_PLATFORM=y
 CONFIG_VIRTIO_PCI=y
 CONFIG_VIRTIO_BALLOON=y
 CONFIG_VIRTIO_MMIO=y
-- 
2.7.4

Re: [PATCH] v4l: vsp1: Fix continuous mode for dual pipelines

[Kieran Bingham]

Hi Laurent,

On 09/02/18 13:27, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Friday, 9 February 2018 15:18:25 EET Kieran Bingham wrote:
>> From: Kieran Bingham 
>>
>> To allow dual pipelines utilising two WPF entities when available, the
>> VSP was updated to support header-mode display list in continuous
>> pipelines.
>>
>> A small bug in the status check of the command register causes the
>> second pipeline to be directly afflicted by the running of the first;
>> appearing as a perceived performance issue with stuttering display.
>>
>> Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
>> comparison corresponds to the correct pipeline.
>>
>> Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
>> lists in continuous mode")
>> Cc: "Stable v4.14+" 
>>
>> Signed-off-by: Kieran Bingham 
> 
> Good catch !
> 
> The patch looks good to me, but I wonder if we shouldn't write the subject 
> line as "v4l: vsp1: Fix header display list status check in continuous mode". 

I'm fine with that,

Will resend with your RB tag.


> Sure, we're fixing continuous mode for dual pipelines, but that's more of a 
> side effect, it's header display lists that are broken as a whole in 
> continuous mode, even if we only use that for dual pipelines right now.
> 
> Apart from that,
> 
> Reviewed-by: Laurent Pinchart 
> 
> Please let me know if you'd like to rewrite the commit message.
> 
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index 8cd03ee45f79..34b5ed2592f8
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct
>> vsp1_dl_manager *dlm) return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
>>& VI6_DL_BODY_SIZE_UPD);
>>  else
>> -return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & 
>> VI6_CMD_UPDHDR));
>> +return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
>> +  & VI6_CMD_UPDHDR);
> 
> /me feels so ashamed.

Bah, it's only a brace out of place. I mean, what harm could it do ... hehe :-)

Personally I still blame the compiler for not picking up on the fact that we
told it to do something we didn't want it to do.

/me ducks to avoid all the items thrown by the compiler guys...

>>  }
>>
>>  static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)

--
Kieran

[PATCH] v4l: vsp1: Fix header display list status check in continuous mode

[Kieran Bingham]

From: Kieran Bingham 

To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.

A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of the first;
appearing as a perceived performance issue with stuttering display.

Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
comparison corresponds to the correct pipeline.

Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
lists in continuous mode")
Cc: "Stable v4.14+" 

Reviewed-by: Laurent Pinchart 
Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8cd03ee45f79..34b5ed2592f8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct 
vsp1_dl_manager *dlm)
return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
  & VI6_DL_BODY_SIZE_UPD);
else
-   return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & 
VI6_CMD_UPDHDR));
+   return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
+ & VI6_CMD_UPDHDR);
 }
 
 static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)
-- 
2.7.4

Re: [PATCH] v4l: vsp1: Fix continuous mode for dual pipelines

[Laurent Pinchart]

Hi Kieran,

Thank you for the patch.

On Friday, 9 February 2018 15:18:25 EET Kieran Bingham wrote:
> From: Kieran Bingham 
> 
> To allow dual pipelines utilising two WPF entities when available, the
> VSP was updated to support header-mode display list in continuous
> pipelines.
> 
> A small bug in the status check of the command register causes the
> second pipeline to be directly afflicted by the running of the first;
> appearing as a perceived performance issue with stuttering display.
> 
> Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
> comparison corresponds to the correct pipeline.
> 
> Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
> lists in continuous mode")
> Cc: "Stable v4.14+" 
> 
> Signed-off-by: Kieran Bingham 

Good catch !

The patch looks good to me, but I wonder if we shouldn't write the subject 
line as "v4l: vsp1: Fix header display list status check in continuous mode". 
Sure, we're fixing continuous mode for dual pipelines, but that's more of a 
side effect, it's header display lists that are broken as a whole in 
continuous mode, even if we only use that for dual pipelines right now.

Apart from that,

Reviewed-by: Laurent Pinchart 

Please let me know if you'd like to rewrite the commit message.

> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c index 8cd03ee45f79..34b5ed2592f8
> 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct
> vsp1_dl_manager *dlm) return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
> & VI6_DL_BODY_SIZE_UPD);
>   else
> - return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & 
> VI6_CMD_UPDHDR));
> + return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
> +   & VI6_CMD_UPDHDR);

/me feels so ashamed.

>  }
> 
>  static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)

-- 
Regards,

Laurent Pinchart

[PATCH] v4l: vsp1: Fix continuous mode for dual pipelines

[Kieran Bingham]

From: Kieran Bingham 

To allow dual pipelines utilising two WPF entities when available, the
VSP was updated to support header-mode display list in continuous
pipelines.

A small bug in the status check of the command register causes the
second pipeline to be directly afflicted by the running of the first;
appearing as a perceived performance issue with stuttering display.

Fix the vsp1_dl_list_hw_update_pending() call to ensure that the read
comparison corresponds to the correct pipeline.

Fixes: eaf4bfad6ad8 ("v4l: vsp1: Add support for header display
lists in continuous mode")
Cc: "Stable v4.14+" 

Signed-off-by: Kieran Bingham 
---
 drivers/media/platform/vsp1/vsp1_dl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 8cd03ee45f79..34b5ed2592f8 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -509,7 +509,8 @@ static bool vsp1_dl_list_hw_update_pending(struct 
vsp1_dl_manager *dlm)
return !!(vsp1_read(vsp1, VI6_DL_BODY_SIZE)
  & VI6_DL_BODY_SIZE_UPD);
else
-   return !!(vsp1_read(vsp1, VI6_CMD(dlm->index) & 
VI6_CMD_UPDHDR));
+   return !!(vsp1_read(vsp1, VI6_CMD(dlm->index))
+ & VI6_CMD_UPDHDR);
 }
 
 static bool vsp1_dl_hw_active(struct vsp1_dl_manager *dlm)
-- 
2.7.4

Re: i2c_new_{secondary_device,dummy,device}() return type.

[Laurent Pinchart]

Hi Kieran,

On Friday, 9 February 2018 12:01:09 EET Kieran Bingham wrote:
> Hi Wolfram,
> 
> As part of my work looking at using i2c_new_secondary_device() to move
> address mappings into the device tree, it has become evident that the
> return code of the i2c_new_secondary_device() is obfuscated, and is simply
> a valid client - or NULL.
> 
> This means that we must 'guess' as to whether the device failed due to a
> memory allocation, or if the device address was already in use (perhaps a
> more common failure).
> 
> Because of this - I would like to see the return codes of
> i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device()
> support returning ERR_PTR()s rather than a client or NULL.
> 
> These functions are used fairly extensively - thus it will be a fair bit of
> work (or a good coccinelle script) - So I'd like to ask your opinion on the
> validity of this task before I commence anything down that rabbit hole!
> 
> Any comments? Pre-ack/nack? (from anyone?)

Pre-ack from me :-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC 00/11] ARM: dts: rcar-gen2: Enable watchdog support

[Geert Uytterhoeven]

On Thu, Feb 8, 2018 at 11:34 AM, Geert Uytterhoeven
 wrote:
> This patch series enables the builtin watchdog timer on R-Car Gen2 SoCs
> on all supported boards, and builds on top of Fabrizio's "[RFC v4 00/26]
> Fix watchdog on Renesas R-Car Gen2 and RZ/G1".  It is marked RFC as it
> is known not to work on all SoCs and SoC revisions.
>
> Based on my experiments, there are 3 success/failure modes:
>
>   1. It works!
>
>  This is the case on R-Car M2-N ES1.0 and E2 ES1.0 (tested on gose
>  and alt).

It also succeeds on R-Car M2-W ES3.0 (tested on porter).

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

i2c_new_{secondary_device,dummy,device}() return type.

[Kieran Bingham]

Hi Wolfram,

As part of my work looking at using i2c_new_secondary_device() to move address
mappings into the device tree, it has become evident that the return code of the
i2c_new_secondary_device() is obfuscated, and is simply a valid client - or 
NULL.

This means that we must 'guess' as to whether the device failed due to a memory
allocation, or if the device address was already in use (perhaps a more common
failure).

Because of this - I would like to see the return codes of
i2c_new_secondary_device(), ic2_new_dummy(), and therefore i2c_new_device()
support returning ERR_PTR()s rather than a client or NULL.

These functions are used fairly extensively - thus it will be a fair bit of work
(or a good coccinelle script) - So I'd like to ask your opinion on the validity
of this task before I commence anything down that rabbit hole!

Any comments? Pre-ack/nack? (from anyone?)

--
Regards

Kieran Bingham

Re: [PATCH 09/11] DT: arm: shmobile: document Condor board bindings

[Simon Horman]

On Thu, Feb 08, 2018 at 02:13:06PM -0600, Rob Herring wrote:
> On Fri, Feb 02, 2018 at 09:45:08PM +0300, Sergei Shtylyov wrote:
> > Document the Condor device tree bindings, listing it as a supported board.
> > 
> > This allows to use checkpatch.pl to validate .dts files referring to the
> > Condor board.
> > 
> > Signed-off-by: Sergei Shtylyov 
> > 
> > ---
> >  Documentation/devicetree/bindings/arm/shmobile.txt |2 ++
> >  1 file changed, 2 insertions(+)
> 
> Reviewed-by: Rob Herring 
> 

On Fri, Feb 09, 2018 at 08:27:34AM +0100, Geert Uytterhoeven wrote:
> On Fri, Feb 2, 2018 at 7:45 PM, Sergei Shtylyov
>  wrote:
> > Document the Condor device tree bindings, listing it as a supported board.
> >
> > This allows to use checkpatch.pl to validate .dts files referring to the
> > Condor board.
> >
> > Signed-off-by: Sergei Shtylyov 
> 
> Reviewed-by: Geert Uytterhoeven 


Thanks, applied with the following subject:

dt-bindings: arm: document Condor board bindings