public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Vinod Koul <vinod.koul@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	spear-devel <spear-devel@list.st.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Subject: Re: [PATCHv3 5/7] dmaengine: dw_dmac: add PCI part of the driver
Date: Mon, 08 Oct 2012 15:46:49 +0300	[thread overview]
Message-ID: <1349700409.10584.118.camel@smile> (raw)
In-Reply-To: <CAKohpokGsAv2cPjj2EMvmTmN1Q+LOU7mN0H9YZcGzs95mm6c-w@mail.gmail.com>

On Mon, 2012-10-08 at 16:19 +0530, Viresh Kumar wrote: 
> On 8 October 2012 15:47, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > This approach has the significant differences to proposed before.
> 
> I am afraid i didn't get your mail completely. Still i will try based on my
> understanding.
Ok, let me try again.

> > First of all it will export IP-block relevant functions to the kernel
> > namespace. I think it is not a good idea to pollute kernel more.
> 
> So, few routines which are required to be called from probe,
> suspend/resume and exit would be made non-static... This is what you
> wanted to say? Hopefully most of the routines would still be declared
> static in the core file. So IMHO, the simplicity or clarity that new approach
> gives has more advantages than this aspect.
The probe (core part), remove, shutdown, suspend, and resume will be
exported. Practically each generic function which will be used in
drivers outside of core. Why do we need them in the kernel namespace?

> > Moreover the API dependencies disallow transparent build and usage of
> > the drivers. For example, you can't built-in platform driver and leave
> > core part as a module.
> Obviously... Should be done this way only...
I could not agree. I don't see any reason why this is the only way.

> What if core driver isn't inserted
> and platform's probe is already called.
Nothing will happen in my case until user loads all necessary bits.

> That's why depends-on should not
> allow you to make core part as module alone...
> I couldn't get the issue completely. What's the problem in this approach?

Why we need to do this if we could avoid it? I see nothing to prevent us
to build parts as modules, or otherwise, or mixed style.
In other words one approach provides weak dependency and the other -
hard dependency between pieces of code.



-- 
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2012-10-08 12:46 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-27  7:31 [PATCHv3 0/7] dw_dmac: split the driver and introduce PCI part Andy Shevchenko
2012-09-27  7:31 ` [PATCHv3 1/7] dmaengine: dw_dmac: use helper macro module_platform_driver() Andy Shevchenko
2012-09-27  7:40   ` Felipe Balbi
2012-09-27  8:16     ` viresh kumar
2012-09-27  8:16       ` Felipe Balbi
2012-10-01 10:47     ` Andy Shevchenko
2012-10-01 13:05       ` Felipe Balbi
2012-09-27  7:31 ` [PATCHv3 2/7] dmaengine: dw_dmac: add module alias Andy Shevchenko
2012-09-27  8:16   ` viresh kumar
2012-09-27  8:16     ` Felipe Balbi
2012-09-27  7:31 ` [PATCHv3 3/7] dmaengine: dw_dmac: remove CLK dependency Andy Shevchenko
2012-09-27  7:42   ` Felipe Balbi
2012-09-27  8:04     ` Andy Shevchenko
2012-09-27  8:02       ` Felipe Balbi
2012-09-27  8:17     ` viresh kumar
2012-09-27  8:17       ` Felipe Balbi
2012-09-27  7:31 ` [PATCHv3 4/7] dmaengine: dw_dmac: amend description and indentation Andy Shevchenko
2012-09-27  7:45   ` Felipe Balbi
2012-09-27  8:19     ` viresh kumar
2012-09-27  8:36       ` Andy Shevchenko
2012-09-27  7:31 ` [PATCHv3 5/7] dmaengine: dw_dmac: add PCI part of the driver Andy Shevchenko
2012-09-27  7:49   ` Felipe Balbi
2012-09-27  8:08     ` Andy Shevchenko
2012-09-27  8:09       ` Felipe Balbi
2012-09-27  8:44   ` Vinod Koul
2012-09-27  9:43     ` Andy Shevchenko
2012-09-27 10:01       ` Vinod Koul
2012-09-27 10:11         ` viresh kumar
2012-09-27 10:32           ` Vinod Koul
2012-10-03 13:40             ` Andy Shevchenko
2012-10-08 10:17           ` Andy Shevchenko
2012-10-08 10:49             ` Viresh Kumar
2012-10-08 12:46               ` Andy Shevchenko [this message]
2012-10-08 13:27                 ` Viresh Kumar
2012-10-24 11:13                   ` Vinod Koul
2012-10-30 15:05                   ` Andy Shevchenko
2012-10-30 15:19                     ` Viresh Kumar
2012-10-30 15:39                       ` Andy Shevchenko
2012-09-27  7:32 ` [PATCHv3 6/7] dma: move dw_dmac driver to an own directory Andy Shevchenko
2012-09-27  7:50   ` Felipe Balbi
2012-09-27  8:22   ` viresh kumar
2012-09-27  8:39     ` Felipe Balbi
2012-09-27  7:32 ` [PATCHv3 7/7] MAINTAINERS: add recently created files to dw_dmac section Andy Shevchenko
2012-09-27  7:51   ` Felipe Balbi
2012-09-27  8:12     ` viresh kumar
2012-09-27  8:24     ` Andy Shevchenko

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=1349700409.10584.118.camel@smile \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spear-devel@list.st.com \
    --cc=vinod.koul@linux.intel.com \
    --cc=viresh.kumar@linaro.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