linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).