From: Jeff Garzik <jgarzik@pobox.com>
To: Anton Vorontsov <cbouatmailru@gmail.com>, Lin Mac <mkl0301@gmail.com>
Cc: htejun@gmail.com, linux-arm-kernel@lists.infradead.org,
linux-ide@vger.kernel.org
Subject: Re: [PATCH v2 0/3] add CNS3xxx AHCI support
Date: Thu, 06 Jan 2011 18:17:56 -0500 [thread overview]
Message-ID: <4D264DA4.6040308@pobox.com> (raw)
In-Reply-To: <20110106105157.GA9560@oksana.dev.rtsoft.ru>
On 01/06/2011 05:51 AM, Anton Vorontsov wrote:
> On Thu, Jan 06, 2011 at 02:43:08PM +0800, Lin Mac wrote:
> [...]
>>> It is overkill to rename the entirety of ahci_platform just for one override
>>> function.
>>> This sort of thing I would have expected to be added directly to
>>> ahci_platform.c.
>> It might be overkill for only one controller. but it is more clean and
>> readable to have different SoC specific changes in separate files,
>> especially when more SoCs need to make similar changes.
>
> I think that renaming the file is not necessary. You can just
> rename the module in the makefile.
>
> Personally I like the current approach more than putting
> controller-specific fixups directly into ahci_platform.
My main objection is the renaming. If ahci_platform wants to export
some symbols for SoC modules like ahci_platform_cns, that's ok.
In general, follow the library approach rather than linking modules
together in strange ways.
Jeff
WARNING: multiple messages have this Message-ID (diff)
From: jgarzik@pobox.com (Jeff Garzik)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/3] add CNS3xxx AHCI support
Date: Thu, 06 Jan 2011 18:17:56 -0500 [thread overview]
Message-ID: <4D264DA4.6040308@pobox.com> (raw)
In-Reply-To: <20110106105157.GA9560@oksana.dev.rtsoft.ru>
On 01/06/2011 05:51 AM, Anton Vorontsov wrote:
> On Thu, Jan 06, 2011 at 02:43:08PM +0800, Lin Mac wrote:
> [...]
>>> It is overkill to rename the entirety of ahci_platform just for one override
>>> function.
>>> This sort of thing I would have expected to be added directly to
>>> ahci_platform.c.
>> It might be overkill for only one controller. but it is more clean and
>> readable to have different SoC specific changes in separate files,
>> especially when more SoCs need to make similar changes.
>
> I think that renaming the file is not necessary. You can just
> rename the module in the makefile.
>
> Personally I like the current approach more than putting
> controller-specific fixups directly into ahci_platform.
My main objection is the renaming. If ahci_platform wants to export
some symbols for SoC modules like ahci_platform_cns, that's ok.
In general, follow the library approach rather than linking modules
together in strange ways.
Jeff
next prev parent reply other threads:[~2011-01-06 23:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-05 5:43 [PATCH v2 0/3] add CNS3xxx AHCI support mkl0301
2011-01-05 5:43 ` mkl0301 at gmail.com
2011-01-05 5:43 ` [PATCH v2 1/3] ahci_platform: rename to ahci_pltfm, but keep the original module name mkl0301
2011-01-05 5:43 ` mkl0301 at gmail.com
2011-01-05 5:43 ` [PATCH v2 2/3] ahci_pltfm: switch to module device table matching mkl0301
2011-01-05 5:43 ` mkl0301 at gmail.com
2011-01-06 10:53 ` Anton Vorontsov
2011-01-06 10:53 ` Anton Vorontsov
2011-01-05 5:43 ` [PATCH v2 3/3] ahci_platform: add support for CNS3xxx SoC devices mkl0301
2011-01-05 5:43 ` mkl0301 at gmail.com
2011-01-06 11:02 ` Anton Vorontsov
2011-01-06 11:02 ` Anton Vorontsov
2011-01-05 18:15 ` [PATCH v2 0/3] add CNS3xxx AHCI support Jeff Garzik
2011-01-05 18:15 ` Jeff Garzik
2011-01-06 6:43 ` Lin Mac
2011-01-06 6:43 ` Lin Mac
2011-01-06 10:51 ` Anton Vorontsov
2011-01-06 10:51 ` Anton Vorontsov
2011-01-06 16:18 ` Lin Mac
2011-01-06 16:18 ` Lin Mac
2011-01-06 23:17 ` Jeff Garzik [this message]
2011-01-06 23:17 ` Jeff Garzik
2011-01-07 15:47 ` Anton Vorontsov
2011-01-07 15:47 ` Anton Vorontsov
2011-01-07 23:44 ` Lin Mac
2011-01-07 23:44 ` Lin Mac
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=4D264DA4.6040308@pobox.com \
--to=jgarzik@pobox.com \
--cc=cbouatmailru@gmail.com \
--cc=htejun@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=mkl0301@gmail.com \
/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.