From: Anton Vorontsov <avorontsov@ru.mvista.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 0/12] ahci: Add support for non-PCI devices
Date: Wed, 3 Mar 2010 16:15:04 +0300 [thread overview]
Message-ID: <20100303131504.GA25973@oksana.dev.rtsoft.ru> (raw)
In-Reply-To: <4B8D846F.3080400@garzik.org>
On Tue, Mar 02, 2010 at 04:34:39PM -0500, Jeff Garzik wrote:
[...]
> As demonstrated in libata-dev.git#libahci, I think the best route is
> to move generic code into libahci. In #libahci you will see
>
> libahci -> common code
> ahci -> standard PCI driver, req's libahci
> mv-ahci -> Marvell AHCI driver, req's libahci
> acard-ahci -> ACard AHCI driver, req's libahci
>
> and to this we could easily add
>
> platform-ahci -> platform AHCI driver, req's libahci
>
> WARNING: #libahci should not be used directly, it is meant for
> illustration purposes only. It has not been properly updated for
> several recent ahci.c changes upstream, which implies that the
> trivial-and-obvious task of moving generic code from ahci.c to
> libahci.c must be redone.
Well, do I understand correctly that the only issue is the
file names? I.e. in my patches, instead of keeping the library
code in ahci.c, I should move the library code into libahci.c,
and keep the PCI code in ahci.c?
Because, as far as I can see, the result of my patches is pretty
much the same as in #libahci, except the file names and more
things that can be reused (i.e. ahci_sht, ahci_ops -- I kept
all this in the library part, since we want to share it with
the platform driver).
Also, I don't export function that aren't currently used
by PCI or platform drivers, but in #libahci there are all
exported. Should I keep it my way, or should I export all the
functions (even if there are no any users of these)?
> P.S. Please use the email addresses in MAINTAINERS,
>
> M: Jeff Garzik <jgarzik@pobox.com>
> L: linux-ide@vger.kernel.org
>
> The redhat.com email address is only used for legal (sign-off)
> purposes, not normal use.
Got it, thanks!
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
next prev parent reply other threads:[~2010-03-03 13:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 18:28 [PATCH RFC 0/12] ahci: Add support for non-PCI devices Anton Vorontsov
2010-03-02 18:29 ` [PATCH 01/12] ahci: Fix some sparse warnings Anton Vorontsov
2010-03-02 18:29 ` [PATCH 02/12] ahci: Get rid of host->iomap usage Anton Vorontsov
2010-03-02 18:29 ` [PATCH 03/12] ahci: Factor out PCI specifics from ahci_save_initial_config() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 04/12] ahci: Get rid of pci_dev argument in ahci_save_initial_config() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 05/12] ahci: Factor out PCI specifics from ahci_reset_controller() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 06/12] ahci: Get rid of pci_dev argument in ahci_port_init() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 07/12] ahci: Factor out PCI specifics from ahci_init_controller() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 08/12] ahci: Factor out PCI specifics from ahci_print_info() Anton Vorontsov
2010-03-02 18:29 ` [PATCH 09/12] ahci: Introduce ahci_set_em_messages() Anton Vorontsov
2010-03-02 21:18 ` Sergei Shtylyov
2010-03-02 23:19 ` Jeff Garzik
2010-03-03 10:40 ` Sergei Shtylyov
2010-03-03 11:41 ` Jeff Garzik
2010-03-03 14:38 ` Greg Freemyer
2010-03-02 18:29 ` [PATCH 10/12] ahci: Move PCI code into ahci_pci.c Anton Vorontsov
2010-03-02 18:29 ` [PATCH 11/12] ahci: Export generic AHCI symbols Anton Vorontsov
2010-03-02 18:29 ` [PATCH 12/12] ahci: Add platform driver Anton Vorontsov
2010-03-02 19:41 ` Sergei Shtylyov
2010-03-03 13:14 ` Anton Vorontsov
2010-03-02 21:34 ` [PATCH RFC 0/12] ahci: Add support for non-PCI devices Jeff Garzik
2010-03-03 13:15 ` Anton Vorontsov [this message]
2010-03-03 13:40 ` Jeff Garzik
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=20100303131504.GA25973@oksana.dev.rtsoft.ru \
--to=avorontsov@ru.mvista.com \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.