All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>,
	ian.campbell@citrix.com, manish.jaggi@caviumnetworks.com,
	tim@xen.org, stefano.stabellini@citrix.com,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH for 4.6 07/13] xen: Introduce a generic way to describe device
Date: Wed, 17 Dec 2014 10:30:22 +0000	[thread overview]
Message-ID: <54915B3E.4010702@linaro.org> (raw)
In-Reply-To: <549165F102000078000502B8@mail.emea.novell.com>

Hi Jan,

On 17/12/2014 10:16, Jan Beulich wrote:
>>>> On 16.12.14 at 21:08, <julien.grall@linaro.org> wrote:
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -2,6 +2,7 @@ obj-y += bitmap.o
>>   obj-y += core_parking.o
>>   obj-y += cpu.o
>>   obj-y += cpupool.o
>> +obj-y += device.o
>
> Shouldn't this instead be two lines, one using HAS_PCI and the second
> HAS_DEVICE_TREE?

When ARM will gain PCI will, it will fail to compile because device.o is 
included twice.

>
>> @@ -75,8 +76,19 @@ struct pci_dev {
>>   #define PT_FAULT_THRESHOLD 10
>>       } fault;
>>       u64 vf_rlen[6];
>> +
>> +    struct device dev;
>>   };
>
> I'm not convinced yet that growing this structure (of which we have
> quite many instances on some systems) is really worth it, in particular
> on x86 where we (so far) only have one device type anyway.

Actually this will growing by only sizeof (enum type) on x86.

Having a generic way to describe device will really help ARM code (see 
IOMMU).

If we don't have a such thing, we may need to duplicate quite a lots of 
code. Which will make hard to maintain.

>> +#define pci_to_dev(pcidev)  (&(pcidev)->dev)
>> +
>> +static inline struct pci_dev *dev_to_pci(struct device *dev)
>> +{
>> +    ASSERT(dev->type == DEV_PCI);
>> +
>> +    return container_of(dev, struct pci_dev, dev);
>> +}
>
> While the former is const-correct, I dislike the inability of passing
> pointers to const into helper functions like the latter. I can't think
> of a good solution other than introducing a second const variant
> of it, but I suppose we should try to find alternatives before
> adding such a construct that moves us in a direction opposite to
> getting our code more const-correct.

Oh right. I didn't though about that case. I will turn this inline 
function into a macro.

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-12-17 10:30 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-16 20:08 [PATCH for 4.6 00/13] xen/arm: Resync the SMMU driver with the Linux one Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 01/13] xen/arm: gic-v2: Change the device name in DT_DEVICE_START Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 02/13] xen/arm: vgic: Drop unecessary include asm/device.h Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 03/13] xen: Introduce ACCESS_ONCE macro Julien Grall
2014-12-17 10:05   ` Jan Beulich
2014-12-17 12:54     ` Julien Grall
2014-12-17 17:10       ` Jan Beulich
2014-12-17 17:52         ` Andrew Cooper
2014-12-18 15:58           ` Julien Grall
2014-12-18 15:58           ` Julien Grall
2015-01-15 13:39           ` Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 04/13] xen/dt: Extend dt_device_match to possibly store data Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 05/13] xen/arm: device: Rename device_type into device_match Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 06/13] xen/iommu: arm: Remove temporary the SMMU driver Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 07/13] xen: Introduce a generic way to describe device Julien Grall
2014-12-17 10:16   ` Jan Beulich
2014-12-17 10:30     ` Julien Grall [this message]
2014-12-17 10:46       ` Jan Beulich
2014-12-17 13:03         ` Julien Grall
2014-12-17 17:17           ` Jan Beulich
2014-12-18 15:56             ` Julien Grall
2014-12-18 16:02               ` Jan Beulich
2014-12-18 16:07                 ` Julien Grall
2014-12-18  1:12   ` Zhang, Yang Z
2014-12-18  8:52     ` Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 08/13] xen/iommu: Consolidate device assignment ops into a single set Julien Grall
2014-12-17 10:20   ` Jan Beulich
2014-12-16 20:08 ` [PATCH for 4.6 09/13] xen/arm: Describe device supported by a driver with dt_match_node Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 10/13] xen/iommu: arm: Import the SMMU driver from Linux Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 11/13] xen/iommu: smmu: Check for duplicate stream IDs when registering master devices Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 12/13] xen/iommu: smmu: Introduce automatic stream-id-masking Julien Grall
2014-12-16 20:08 ` [PATCH for 4.6 13/13] xen/iommu: smmu: Add Xen specific code to be able to use the driver Julien Grall
2015-02-18  1:02   ` Manish
2015-02-18 11:47     ` Julien Grall
2015-02-18 11:54       ` Julien Grall
2015-02-18 17:30         ` Jaggi, Manish
2015-02-18 18:22           ` Julien Grall
2015-02-19  2:55             ` Manish
2015-02-19  6:01               ` Julien Grall
2015-02-19  7:16                 ` Manish
2015-02-19 10:34               ` Andrew Cooper

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=54915B3E.4010702@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=JBeulich@suse.com \
    --cc=ian.campbell@citrix.com \
    --cc=keir@xen.org \
    --cc=manish.jaggi@caviumnetworks.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=tim@xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.