From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: David Daney <ddaney@caviumnetworks.com>,
linux-serial@vger.kernel.org, gregkh@suse.de,
linux-kernel@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org
Subject: Re: [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration.
Date: Thu, 17 Mar 2011 23:48:14 +0000 [thread overview]
Message-ID: <20110317234814.421f1aa4@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20110317193149.GD12824@angua.secretlab.ca>
> Device registration isn't the problem. The problem is supplying
> machine-specific callbacks from the board support code to the
> drivers. When devices are sourced from a device tree, it is easy to
> get data about the device out of the tree, but it is really hard to
> get callback pointers. To make it all work without this fiddling
> about, the octeon serial_{in,out} implementation would need to be
> rolled into of_serial.c (which FWIW, I have absolutely no problem
> with).
Disagree - the arch code needs to register I/O method descriptions with
the of_serial code they don't neccessarily need to be in it.
Ie you'd have something like
of_serial8250_register_ops("dt-op-type-name-blah", &ops);
in the early boot code, and the ops can be in the arch, providing the ops
has a module owner field the rest can even work modular. Sure the stuff
should be able to describe standard forms directly without extra methods
being registered but for the special stuff I think that is the right
approach
Funnily enough I'm in the middle of trying to rip the rm9k, au and other
crap out of 8250.c by doing this for the UPIO_xxx ids and once you have
an ops struct you can also then go and boot out the resource claim crap
and package it all nicely.
next prev parent reply other threads:[~2011-03-17 23:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 1:26 [RFC PATCH 0/2] serial: Hack up 8520.c for evil device tree hookin David Daney
2011-03-17 1:26 ` [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration David Daney
2011-03-17 12:18 ` Alan Cox
2011-03-17 16:42 ` David Daney
2011-03-17 18:25 ` Grant Likely
2011-03-17 18:42 ` David Daney
2011-03-17 18:47 ` Grant Likely
2011-03-17 19:24 ` Alan Cox
2011-03-17 19:31 ` Grant Likely
2011-03-17 20:13 ` David Daney
2011-03-17 20:31 ` Grant Likely
2011-03-17 23:48 ` Alan Cox [this message]
2011-03-18 5:18 ` Grant Likely
2011-03-17 1:26 ` [RFC PATCH 2/2] MIPS: Octeon: Use device tree to register serial ports David Daney
2011-03-17 18:28 ` Grant Likely
2011-03-17 18:35 ` David Daney
2011-03-17 1:46 ` [RFC PATCH 0/2] serial: Hack up 8520.c for evil device tree hookin Alan Cox
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=20110317234814.421f1aa4@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=ddaney@caviumnetworks.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.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
all inboxes | Powered by JetHome®