From: Grant Likely <grant.likely@secretlab.ca>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: "Kári Davíðsson" <kari.davidsson@marel.com>,
spi-devel-general@lists.sourceforge.net, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] mpc52xx-psc-spi: refactor probe and remove to make use of of_register_spi_devices()
Date: Mon, 2 Nov 2009 09:08:31 -0700 [thread overview]
Message-ID: <fa686aa40911020808n73a898ack5fb66933188555da@mail.gmail.com> (raw)
In-Reply-To: <20091102131427.GB4696@pengutronix.de>
On Mon, Nov 2, 2009 at 6:14 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>> Also, I'm resistant to changing the probe layout on this driver at
>> this time. With the work being done to generalize the OF support
>> code, there is a strong possibility that of_platform will be
>> deprecated in favor of going back to using the platform bus directly
>> (just like how OF support works for i2c, spi, etc). I'd rather not
>> refactor the driver until I'm certain of the direction that things are
>> going to go.
>
> And this was possibly the best answer I could get \o/ Sounds really promising,
> is there somewhere a discussion about how OF-generalization could happen?
It has been discussed on-and-off on the mailing list and on IRC.
There are 2 major problems that need to be solved before it can be
done:
1. Figure out how to do OF-style driver probing with the platform bus.
I could use the same heuristic as used by i2c & spi, but that
approach isn't very scalable, and doesn't handle backwards
compatibility very well.
2. Figure out the best way to extract platform data from the device
tree without having a huge impact on the device drivers. The adapter
code still driver specific, so it needs to be part of the device
driver itself, but I want to establish a pattern which does not
require major surgery to platform drivers in order to add OF support.
>> - return mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
>> + rc = mpc52xx_psc_spi_do_probe(&op->dev, (u32)regaddr64, (u32)size64,
>> irq_of_parse_and_map(op->node, 0), id);
>> + if (!rc)
>
> A matter of taste, maybe: I'd prefer
>
> if (rc == 0)
>
> as (!ptr) is often used for catching errors with pointers, but here it is the
> 'all went OK'-path.
Okay, I'll change this. Thanks for the feedback.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next prev parent reply other threads:[~2009-11-02 16:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-30 19:44 [PATCH] mpc52xx-psc-spi: refactor probe and remove to make use of of_register_spi_devices() Wolfram Sang
2009-10-31 5:32 ` Stephen Rothwell
2009-10-31 9:03 ` Wolfram Sang
2009-11-01 1:03 ` Grant Likely
2009-11-02 13:14 ` Wolfram Sang
2009-11-02 16:08 ` Grant Likely [this message]
[not found] ` <fa686aa40911020808n73a898ack5fb66933188555da-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-11-03 11:43 ` [PATCH] mpc52xx-psc-spi: Enumerate child nodes in the OF tree Kári Davíðsson
[not found] ` <4AF01751.1090806-zCUwNCi8n9MAvxtiuMwx3w@public.gmane.org>
2009-11-03 13:05 ` Wolfram Sang
[not found] ` <20091103130515.GS3571-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-11-03 13:47 ` Grant Likely
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=fa686aa40911020808n73a898ack5fb66933188555da@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=kari.davidsson@marel.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=spi-devel-general@lists.sourceforge.net \
--cc=w.sang@pengutronix.de \
/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).