From: Rob Herring <robh@kernel.org>
To: Jan Viktorin <viktorin@rehivetech.com>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"Hans J. Koch" <hjk@hansjkoch.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH 3/4] uio: introduce devicetree bindings for uio_dmem_genirq
Date: Mon, 23 May 2016 15:36:22 -0500 [thread overview]
Message-ID: <20160523203622.GA11818@rob-hp-laptop> (raw)
In-Reply-To: <20160519104556.739c3f68@pcviktorin.fit.vutbr.cz>
On Thu, May 19, 2016 at 10:45:56AM +0200, Jan Viktorin wrote:
> Hello Rob,
>
> thank you for your opinion...
>
> On Wed, 18 May 2016 12:01:05 -0500
> Rob Herring <robh@kernel.org> wrote:
>
> > On Tue, May 17, 2016 at 11:22:19AM +0200, Jan Viktorin wrote:
> > > Signed-off-by: Jan Viktorin <viktorin@rehivetech.com>
> > > ---
> > > .../devicetree/bindings/uio/uio_dmem_genirq.txt | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/uio/uio_dmem_genirq.txt
> >
> > DT describes h/w. UIO is not a h/w block, so this does not belong in DT.
> > A UIO vs. kernel driver is purely a kernel decision which shouldn't
> > require a DT change.
>
> I mostly agree and I don't say this is the very best solution... however,
> it is quite a straightforward one.
>
> >
> > The properties should be part of match data for a compatible string that
>
> True. But in case of probing from DT, where can I obtain those match data
> from? I have to patch the kernel... and that is what I tried to avoid.
spi-dev is a similar situation and we put compatible strings (and
therefore potentially match data) in the kernel.
> With this patch set, you only modify your current device-tree (extend the
> appropriate devices by "uio,...") and reboot with this new one.
Generally speaking changing your kernel is as easy or easier than
changing the DT.
Rebooting is not a very good choice either when it could easily be a
module unload/reload instead.
> > needs them set. Or if they can be defined in a way that is actually a
> > property of the h/w, then it would be acceptible. You'd still need to
> > define compatible strings that the properties apply to.
>
> If you look at uio_pdrv_genirq you can see that it has already been extended by
> the module param "of_id". I.e. it is possible to specify the compatible property
> it would match when doing insmod. So, it is possible to bind it to any platform
> device described by the device tree. And thus, there is no way how to define a
> list of compatible strings for it... (quite a long list, isn't it?)
>
> The same (of_id) can be done for uio_dmem_genirq, however, there is no way how to
> specify the amount of dynamic memory to be used for a specific device. For me, it
> makes sense to use DT to obtain those two properties saying "those devices would
> use this amount of memory and not more".
>
> Perhaps, another module param is a way to go here. Something like of_dmem_count=2,
> of_dmem_sizes=32k. Less flexible solution, however, if it is acceptable I'll rewrite
> the current one.
No issue with doing that, though they are not OF parameters at that
point.
Rob
next prev parent reply other threads:[~2016-05-23 20:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-17 9:22 [PATCH 0/4] Fix and extend uio_dmem_genirq Jan Viktorin
2016-05-17 9:22 ` [PATCH 1/4] uio: fix dmem_region_start computation Jan Viktorin
2016-05-17 9:22 ` [PATCH 2/4] uio: UIO_IRQ_NONE is a valid option for uioinfo->irq Jan Viktorin
2016-08-31 11:04 ` Greg Kroah-Hartman
2016-05-17 9:22 ` [PATCH 3/4] uio: introduce devicetree bindings for uio_dmem_genirq Jan Viktorin
2016-05-18 17:01 ` Rob Herring
2016-05-19 8:45 ` Jan Viktorin
2016-05-23 20:36 ` Rob Herring [this message]
2016-06-23 8:31 ` Anup Patel
2016-05-17 9:22 ` [PATCH 4/4] uio: bind uio_pdrv_genirq via OF Jan Viktorin
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=20160523203622.GA11818@rob-hp-laptop \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=gregkh@linuxfoundation.org \
--cc=hjk@hansjkoch.de \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=viktorin@rehivetech.com \
/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).