linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <info@metux.net>
To: linux-kernel@vger.kernel.org
Cc: vireshk@kernel.org, b.zolnierkie@samsung.com, axboe@kernel.dk,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	linux-ide@vger.kernel.org, linux-block@vger.kernel.org,
	linux-crypto@vger.kernel.org
Subject: RFC: declaring DT match tables (2nd take)
Date: Sat,  1 Jun 2019 15:52:55 +0200	[thread overview]
Message-ID: <1559397179-5833-1-git-send-email-info@metux.net> (raw)

Hi folks,


few days ago I've posted a RFC for getting rid of many #ifdef CONFIG_OF
cases by using a macro that checks for it on its own.
(see: "RFC: get rid of #ifdef CONFIG_OF's around of match tables")

I've already mentioned I'm working on another approach that not just
cares about adding the table to the module, but the also the declaration
of the table itself. Here it is:

Introducing a macro MODULE_DECLARE_OF_TABLE(foo, entries), which declares
a static struct of_device_id array, fills in the entries (automatically
adds the sentinel) and calls MODULE_DEVICE_TABLE() - if CONFIG_OF is
enabled.

The current version isn't fully noop in absence of CONFIG_OF, but also
declares a static const *pointer* variable, initialized NULL, with the
same name. The idea behind: we don't need to use of_match_ptr() anymore.

I believe, the compiler should be clever enough to find out that this
field is always NULL and can't ever change, so it can be easily optimized
away. (correct me if I'm wrong).


Please have a look at the following example patches and let me know,
whether we can go that way. If you're okay w/ that, I'll continue
w/ converting the whole tree to using this approach. I've already did
most of it, yet needs to be sorted out into easily digestable patches :)
And I'd also do the same w/ the other table types (ACPI, PCI, I2C, ...)

By the way: an interesting question arises: shall that conversion be
done *everywhere*, or just those sites where explicit CONFIG_OF's are
involved ?


have fun,

--mtx

             reply	other threads:[~2019-06-01 13:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-01 13:52 Enrico Weigelt, metux IT consult [this message]
2019-06-01 13:52 ` [PATCH 1/4] mod_devicetable: helper macro for declaring oftree module device table Enrico Weigelt, metux IT consult
2019-06-01 13:52 ` [PATCH 2/4] drivers: block: xsysace: use MODULE_DECLARE_OF_TABLE() and of_match_ptr() Enrico Weigelt, metux IT consult
2019-06-01 13:52 ` [PATCH 3/4] drivers: crypto: picoxcell_crypto: use MODULE_DECLARE_OF_TABLE() Enrico Weigelt, metux IT consult
2019-06-01 13:52 ` [PATCH 4/4] drivers: ata: " Enrico Weigelt, metux IT consult

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=1559397179-5833-1-git-send-email-info@metux.net \
    --to=info@metux.net \
    --cc=axboe@kernel.dk \
    --cc=b.zolnierkie@samsung.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vireshk@kernel.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).