From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling
Date: Fri, 12 Feb 2016 15:55:18 +0000 [thread overview]
Message-ID: <20160212155517.GQ25087@arm.com> (raw)
In-Reply-To: <56BDF8D8.4010200@arm.com>
On Fri, Feb 12, 2016 at 03:23:04PM +0000, Robin Murphy wrote:
> On 12/02/16 12:32, Laurent Pinchart wrote:
> >On Friday 12 February 2016 12:08:58 Will Deacon wrote:
> >>On Thu, Feb 11, 2016 at 04:13:45PM +0000, Robin Murphy wrote:
> >>>@@ -173,10 +187,12 @@ static inline void io_pgtable_tlb_sync(struct
> >>>io_pgtable *iop)
> >>> *
> >>> * @alloc: Allocate a set of page tables described by cfg.
> >>> * @free: Free the page tables associated with iop.
> >>>+ * @supported_quirks: Bitmap of quirks supported by the format.
> >>> */
> >>> struct io_pgtable_init_fns {
> >>> struct io_pgtable *(*alloc)(struct io_pgtable_cfg *cfg, void
> >*cookie);
> >>> void (*free)(struct io_pgtable *iop);
> >>>+ unsigned int supported_quirks;
> >>> };
> >>
> >>My only gripe here is that this is supposed to be a struct of function
> >>pointers... get_supported_quirks() ?
> >
> >Can't we instead say it's a struct of function pointers and static data ? :-)
> >A function to retrieve the supported quirks will just contribute to kernel
> >bloat without adding any extra benefit.
>
> Bleh - personally I think it's marginally more obvious and readable to have
> the information looking like data, but I'd much sooner just have a
> hard-coded "if (cfq->quirks & ..." check in every format's alloc function
> than introduce a whole new callback. Does that sound like a reasonable
> compromise?
Yeah, do that. You never know, there could be quirks that are only supported
based on other things in the cfg, so it's more extensible that way too.
Will
next prev parent reply other threads:[~2016-02-12 15:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 17:13 [PATCH v3 0/3] io-pgtable ARM short descriptor format Robin Murphy
2016-01-26 17:13 ` [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor support Robin Murphy
2016-01-27 1:16 ` Yong Wu
2016-01-28 13:41 ` Robin Murphy
2016-02-17 14:31 ` Will Deacon
2016-02-17 14:34 ` Robin Murphy
2016-02-10 15:48 ` Will Deacon
2016-02-11 16:13 ` [PATCH 4/3] iommu/io-pgtable: Rationalise quirk handling Robin Murphy
2016-02-11 20:39 ` Laurent Pinchart
2016-02-12 12:08 ` Will Deacon
2016-02-12 12:32 ` Laurent Pinchart
2016-02-12 15:23 ` Robin Murphy
2016-02-12 15:55 ` Will Deacon [this message]
2016-03-01 12:01 ` [PATCH v3 1/3] iommu/io-pgtable: Add ARMv7 short descriptor support Geert Uytterhoeven
2016-03-01 13:13 ` Laurent Pinchart
2016-03-01 13:51 ` Robin Murphy
2016-01-26 17:13 ` [PATCH v3 2/3] iommu/io-pgtable: Add helper functions for TLB ops Robin Murphy
2016-01-26 17:13 ` [PATCH v3 3/3] iommu/io-pgtable: Avoid redundant TLB syncs Robin Murphy
2016-02-10 14:21 ` Will Deacon
2016-02-12 17:09 ` [PATCH v2] iommu/io-pgtable: Rationalise quirk handling Robin Murphy
2016-02-12 17:24 ` Laurent Pinchart
2016-02-12 17:25 ` Robin Murphy
2016-02-12 17:27 ` Will Deacon
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=20160212155517.GQ25087@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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