From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: 3ds_debugboard: Let ethernet be functional again
Date: Fri, 17 Feb 2012 08:29:09 -0800 [thread overview]
Message-ID: <20120217162909.GA10146@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120217074007.GM3852@pengutronix.de>
On Fri, Feb 17, 2012 at 08:40:07AM +0100, Sascha Hauer wrote:
> On Thu, Feb 16, 2012 at 08:27:04AM -0800, Mark Brown wrote:
> > Oh, in that case it seems really odd that it's returning a pointer to
> > the device rather than just returning success or failure.
> It has to as it gives you a pointer which you can use to unregister the
> device later. Also it's in line with the platform helpers like
> platform_device_register_resndata, platform_device_register_simple and
> others.
Hrm, right. Again I'd expect all users to be in board code so not ever
unregistering anything.
> > In all these cases there is actually a physical supply of some kind; if
> > there isn't one then you'd expect the driver would have explicit code to
> > handle that in some way.
> Yes, there is one. But I think it will only be described in the device
> tree if it's software controllable.
I don't see why that needs to be the case.
> > without making an effort to go round all the uers and at least notify
> > the existing users of the device that they need updates. There's a
> > limited amount we can do in the core
> Are you then willing to merge my patch to make it easier to not break
> boards? I would remove the voltage parameter and fix a remaining
> Kconfig/ifdef issue then.
Well, if you send a patch that looks sensible and is signed off and
whatnot yes. I've no problem with a helper function.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120217/e681d441/attachment.sig>
next prev parent reply other threads:[~2012-02-17 16:29 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-07 20:27 [PATCH] ARM: 3ds_debugboard: Let ethernet be functional again Fabio Estevam
2012-02-13 8:27 ` Sascha Hauer
2012-02-13 12:18 ` Fabio Estevam
2012-02-13 14:48 ` Mark Brown
2012-02-14 10:58 ` Sascha Hauer
2012-02-14 17:29 ` Mark Brown
2012-02-16 7:32 ` Sascha Hauer
2012-02-16 7:58 ` Mark Brown
2012-02-16 9:13 ` Sascha Hauer
2012-02-16 16:27 ` Mark Brown
2012-02-17 7:40 ` Sascha Hauer
2012-02-17 16:29 ` Mark Brown [this message]
2012-02-27 9:04 ` Sascha Hauer
2012-02-27 13:29 ` Mark Brown
2012-02-27 17:20 ` Sascha Hauer
2012-02-27 23:54 ` Mark Brown
2012-02-28 8:27 ` Sascha Hauer
2012-02-28 10:52 ` Mark Brown
2012-02-29 8:33 ` Sascha Hauer
2012-02-29 10:00 ` Mark Brown
2012-03-01 10:08 ` Sascha Hauer
2012-03-01 10:52 ` Mark Brown
2012-03-01 18:20 ` Sascha Hauer
2012-03-01 18:21 ` Mark Brown
2012-03-01 18:30 ` Sascha Hauer
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=20120217162909.GA10146@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.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).