From: Anton Vorontsov <avorontsov-hkdhdckH98+B+jHODAdFcQ@public.gmane.org>
To: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org,
linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC] misc/at24: add experimental OF support for the generic eeprom driver
Date: Fri, 9 Oct 2009 02:20:43 +0400 [thread overview]
Message-ID: <20091008222042.GA10743@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <fa686aa40910080848r459c47baob73fc70a95a08604-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Oct 08, 2009 at 09:48:50AM -0600, Grant Likely wrote:
> On Thu, Oct 8, 2009 at 9:10 AM, Anton Vorontsov
[...]
> > It's *always* a small amound of code, at a start. Then we get
> > floppy disk drivers and the tty layer. ;-)
>
> Holy straw man argument Batman!
>
> But the focus is still on creating pdata. If a translator gets too
> big, then sure, split it into a separate file. Until then, there I
> see no good reason to do so now.
Luckily, I'm not at24 driver maintainer (Wolfram himself is ;-),
but as a maintainer of driver "Foo", I would not want to see
completely unfamiliar "Bar" in my shiny driver.
Another plus is that you can bypass (or almost bypass) subsystem
maintainers when merging OF-specific patches (since he/she couldn't
possibly care less about all these weird arch internals. But again,
this doesn't work for this particular driver since Wolfram is the
maintainer :-).
> > If I wasn't a PPC/OF guy to some degree, I'd hate PPC/OF people
> > for bringing arch-specific details into a generic code... :-P
>
> No, this goes beyond PPC/OF. The real issue is that it is no longer a
> safe assumption that pdata will be a static data structure in platform
> code. The number of possible data sources is going to get larger, not
> smaller. OF is just one. UEFI is another. Translating that data
> into pdata will be the problem that comes up over and over again.
> However, translation code is still driver specific,
> so it belongs with the driver that it translates code for.
Wait... The translation code depends on a platform, and on a
platform_data structure, the same as non-OF arch-specific code
depends on it. How is it different from a static platform data
in the arch/ code? We don't put static platform data into the
drivers and surround them with ugly #ifdefs+machine_is()...
> So, in my opinion, translation code must:
> 1. be *tiny*
Yeah, dream on. ;-) It's tiny when all you have is of_get_property(),
I'd like to see the code when you'll have GPIOs, IRQs, and platform-
specific fixups.
You might say that at24 doesn't need that stuff, but it does.
Suppose AT24's WP pin is connected to a GPIO, and without
'read-only' property I'd like the driver to pull the pin low,
and vice versa: with 'read-only' specifier, WP should be tied
high. Or if WP is controlled by a switch/jumper, GPIO can be
used to read current WP state.
> -- should be trivial to add to a driver without impacting
> common code
This is doable, yes.
> > No matter how small the OF code is, I believe we shouldn't put it
> > into the generic code. Take a look at mmc_spi case again, it can be
> > easily extended to any arch, because there is no arch-specific stuff,
> > but a "get/put" pattern for platform data.
>
> I'm not disagreeing with you that the arch specific stuff should be
> logically separated from the generic code. But I don't agree that it
> belongs in a separate file. And I also think that the mmc_spi
> implementation uses too much code. There must be a better way.
I wonder how you'd shrink the mmc_spi bindings, can you elaborate?
Thanks,
--
Anton Vorontsov
email: cbouatmailru-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2009-10-08 22:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1255010672-21656-1-git-send-email-w.sang@pengutronix.de>
[not found] ` <20091008143301.GA6084@oksana.dev.rtsoft.ru>
[not found] ` <fa686aa40910080753v6f597b0h4ce835db9f7a653@mail.gmail.com>
[not found] ` <20091008151007.GA21328@oksana.dev.rtsoft.ru>
2009-10-08 15:48 ` [RFC] misc/at24: add experimental OF support for the generic eeprom driver Grant Likely
2009-10-08 20:27 ` Wolfram Sang
2009-10-09 5:14 ` Wolfram Sang
[not found] ` <20091009051409.GA2361-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2009-10-09 5:40 ` Grant Likely
2009-10-09 14:01 ` Nate Case
2009-10-09 16:09 ` Grant Likely
2009-10-09 16:20 ` Wolfram Sang
2009-10-09 13:43 ` Nate Case
2009-10-09 16:12 ` Wolfram Sang
2009-10-09 16:13 ` Grant Likely
[not found] ` <fa686aa40910080848r459c47baob73fc70a95a08604-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-10-08 22:20 ` Anton Vorontsov [this message]
2009-10-09 6:37 ` 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=20091008222042.GA10743@oksana.dev.rtsoft.ru \
--to=avorontsov-hkdhdckh98+b+jhodadfcq@public.gmane.org \
--cc=devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org \
--cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
--cc=linux-embedded-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.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).