From: Oleksandr <olekstysh@gmail.com>
To: Julien Grall <julien.grall@arm.com>, xen-devel@lists.xenproject.org
Cc: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>,
sstabellini@kernel.org
Subject: Re: [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support
Date: Tue, 13 Aug 2019 18:17:22 +0300 [thread overview]
Message-ID: <72b1672a-8774-add8-a9f9-216fbd872b83@gmail.com> (raw)
In-Reply-To: <33ac8ed2-572f-a7d8-ddfa-17f6dd50f0f8@arm.com>
On 13.08.19 15:39, Julien Grall wrote:
> Hi Oleksandr,
Hi Julien.
>
> On 8/2/19 5:39 PM, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> We need to have some abstract way to add new device to the IOMMU
>> based on the generic IOMMU DT binding [1] which can be used for
>> both DT (right now) and ACPI (in future).
>>
>> For that reason we can borrow the idea used in Linux these days
>> called "iommu_fwspec". Having this in, it will be possible
>> to configure IOMMU master interfaces of the device (device IDs)
>> from a single common place and avoid keeping almost identifical look-up
>
> s/identifical/identical/
ok
>
>> implementations in each IOMMU driver.
>>
>> There is no need to port the whole implementation of "iommu_fwspec"
>> to Xen, we could, probably, end up with a much simpler solution,
>> some "stripped down" version which fits our requirments.
>
> s/requirments/requirements/
ok
>
>> + */
>> +
>> +#include <xen/lib.h>
>> +#include <xen/iommu.h>
>
> Please order the headers alphabetically.
>
> NIT: Can you a newline between xen and asm headers?
Will do
>
>> +#include <asm/device.h>
>> +#include <asm/iommu_fwspec.h>
>
>> +
>> +int iommu_fwspec_init(struct device *dev, struct device *iommu_dev)
>> +{
>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>> +
>> + if ( fwspec )
>> + return 0;
>> +
>> + fwspec = xzalloc(struct iommu_fwspec);
>> + if ( !fwspec )
>> + return -ENOMEM;
>> +
>> + fwspec->iommu_dev = iommu_dev;
>> + dev_iommu_fwspec_set(dev, fwspec);
>> +
>> + return 0;
>> +}
>> +
>> +void iommu_fwspec_free(struct device *dev)
>> +{
>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>> +
>> + if ( fwspec )
>
> xfree is able to deal with NULL pointer, so the check is not necessary.
Yes, the reason I left this check is to not perform an extra operation
(dev_iommu_fwspec_set). Shall I drop this check anyway?
>
>> + {
>> + xfree(fwspec);
>> + dev_iommu_fwspec_set(dev, NULL);
>> + }
>> +}
>> +
>> +int iommu_fwspec_add_ids(struct device *dev, uint32_t *ids, int
>> num_ids)
>
> While I realize the prototype is coming from Linux, num_ids cannot be
> negative (the code below would not work properly). So the parameter
> should be unsigned.
Agree, will use unsigned.
>
>> +{
>> + struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
>> + size_t size;
>> + int i;
>
> Any variable that can't be negative should be unsigned.
Yes, will follow.
>> diff --git a/xen/include/asm-arm/iommu.h b/xen/include/asm-arm/iommu.h
>> index 20d865e..1853bd9 100644
>> --- a/xen/include/asm-arm/iommu.h
>> +++ b/xen/include/asm-arm/iommu.h
>> @@ -14,6 +14,8 @@
>> #ifndef __ARCH_ARM_IOMMU_H__
>> #define __ARCH_ARM_IOMMU_H__
>> +#include <asm/iommu_fwspec.h>
>
> iommu.h does not seem to use anything defined in iommu_fwspec.h. So
> why do you include it here?
I was thinking that every source which includes iommu.h will get
iommu_fwspec.h included indirectly. No need to include iommu_fwspec.h in
many sources.
This was a reason. Shall I included it directly where needed?
>
>> +
>> struct arch_iommu
>> {
>> /* Private information for the IOMMU drivers */
>> diff --git a/xen/include/asm-arm/iommu_fwspec.h
>> b/xen/include/asm-arm/iommu_fwspec.h
>> new file mode 100644
>> index 0000000..0676285
>> --- /dev/null
>> +++ b/xen/include/asm-arm/iommu_fwspec.h
>> @@ -0,0 +1,65 @@
>> +/*
>> + * xen/include/asm-arm/iommu_fwspec.h
>> + *
>> + * Contains a common structure to hold the per-device firmware data and
>> + * declaration of functions used to maintain that data
>> + *
>> + * Based on Linux's iommu_fwspec support you can find at:
>> + * include/linux/iommu.h
>> + *
>> + * Copyright (C) 2019 EPAM Systems Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms and conditions of the GNU General Public
>> + * License, version 2, as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public
>> + * License along with this program; If not, see
>> <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#ifndef __ARCH_ARM_IOMMU_FWSPEC_H__
>> +#define __ARCH_ARM_IOMMU_FWSPEC_H__
>> +
>> +/* per-device IOMMU instance data */
>> +struct iommu_fwspec {
>> + /* device which represents this IOMMU H/W */
>
> Did you intend to say "this device's IOMMU"?
Exactly)
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-08-13 15:17 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-02 16:39 [Xen-devel] [PATCH V2 0/6] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec Oleksandr Tyshchenko
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 1/6] iommu/arm: Add iommu_helpers.c file to keep common for IOMMUs stuff Oleksandr Tyshchenko
2019-08-09 17:35 ` Julien Grall
2019-08-09 18:10 ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 2/6] iommu/arm: Add ability to handle deferred probing request Oleksandr Tyshchenko
2019-08-12 11:11 ` Julien Grall
2019-08-12 12:01 ` Oleksandr
2019-08-12 19:46 ` Julien Grall
2019-08-13 12:35 ` Oleksandr
2019-08-14 17:34 ` Julien Grall
2019-08-14 19:25 ` Stefano Stabellini
2019-08-15 9:29 ` Julien Grall
2019-08-15 12:54 ` Julien Grall
2019-08-15 13:14 ` Oleksandr
2019-08-15 16:39 ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 3/6] [RFC] xen/common: Introduce _xrealloc function Oleksandr Tyshchenko
2019-08-05 10:02 ` Jan Beulich
2019-08-06 18:50 ` Oleksandr
2019-08-07 6:22 ` Jan Beulich
2019-08-07 17:31 ` Oleksandr
2019-08-06 19:51 ` Volodymyr Babchuk
2019-08-07 6:26 ` Jan Beulich
2019-08-07 18:36 ` Oleksandr
2019-08-08 6:08 ` Jan Beulich
2019-08-08 7:05 ` Jan Beulich
2019-08-08 11:05 ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 4/6] iommu/arm: Add lightweight iommu_fwspec support Oleksandr Tyshchenko
2019-08-13 12:39 ` Julien Grall
2019-08-13 15:17 ` Oleksandr [this message]
2019-08-13 15:28 ` Julien Grall
2019-08-13 16:18 ` Oleksandr
2019-08-13 13:40 ` Julien Grall
2019-08-13 16:28 ` Oleksandr
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 5/6] iommu/arm: Introduce iommu_add_dt_device API Oleksandr Tyshchenko
2019-08-13 13:49 ` Julien Grall
2019-08-13 16:05 ` Oleksandr
2019-08-13 17:13 ` Julien Grall
2019-08-02 16:39 ` [Xen-devel] [PATCH V2 6/6] iommu/arm: Add Renesas IPMMU-VMSA support Oleksandr Tyshchenko
2019-08-07 2:41 ` Yoshihiro Shimoda
2019-08-07 16:01 ` Oleksandr
2019-08-07 19:15 ` Julien Grall
2019-08-07 20:28 ` Oleksandr Tyshchenko
2019-08-08 9:05 ` Julien Grall
2019-08-08 10:14 ` Oleksandr
2019-08-08 12:44 ` Julien Grall
2019-08-08 15:04 ` Oleksandr
2019-08-08 17:16 ` Julien Grall
2019-08-08 19:29 ` Oleksandr
2019-08-08 20:32 ` Julien Grall
2019-08-08 23:32 ` Oleksandr Tyshchenko
2019-08-09 9:56 ` Julien Grall
2019-08-09 18:38 ` Oleksandr
2019-08-08 12:28 ` Oleksandr
2019-08-08 14:23 ` Lars Kurth
2019-08-08 4:05 ` Yoshihiro Shimoda
2019-08-14 17:38 ` Julien Grall
2019-08-14 18:45 ` Oleksandr
2019-08-05 7:58 ` [Xen-devel] [PATCH V2 0/6] iommu/arm: Add Renesas IPMMU-VMSA support + Linux's iommu_fwspec Oleksandr
2019-08-05 8:29 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=72b1672a-8774-add8-a9f9-216fbd872b83@gmail.com \
--to=olekstysh@gmail.com \
--cc=julien.grall@arm.com \
--cc=oleksandr_tyshchenko@epam.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).