All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Jian <lark@linux.net.cn>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org, linux-ide@vger.kernel.org,
	Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH RFC] pata_platform: add 8 bit data io support
Date: Sun, 12 Oct 2008 10:19:41 +0800	[thread overview]
Message-ID: <48F15EBD.4040807@linux.net.cn> (raw)
In-Reply-To: <1223763687.8157.178.camel@pasglop>

Benjamin Herrenschmidt 写道:
> On Sun, 2008-10-12 at 02:00 +0800, Wang Jian wrote:
>> To avoid adding another rare used ata_port member, new bit is added to
>> ata_port->flags.
>>
>> Originally, I hacked pata_platform to make it 8bit only to support 8bit
>> data wired CF card. This patch is more generic.
>>
>> With this patch, __pata_platform_probe() interface is changed, and
>> pata_of_platform is broken, so a small patch is needed.
>>
>> Signed-off-by: Wang Jian <lark@linux.net.cn>
>> ---
> 
> A couple of things. First I would personally prefer (but I'm not the
> libata maintainer so it's up to Jeff ...) if you had a separate patch
> that adds the 8-bit support to libata core first, and then a patch that
> modifies pata_platform.

I will do that if my 8-bit mode patch is done right technically.

> 
> Then, in order to avoid breaking bisection, I would like you to fixup
> pata_of_platform in the same patch that modifies __pata_platform_probe
> so there is no breakage in between patches.

Yes.

> 
> Now, regarding the patch itself, if the core grows a 8-bit flag, then
> I strongly suspect the core should also grow the 8-bit xfer function
> rather than having it hidden in pata_platform.

This is the main reason I send a single RFC patch. Where to add 8-bit
mode should be decided first.

Because 8-bit mode is mostly used for embedded devices, my opinion is
8-bit mode in pata_platform is enough.

However, look at pata_platform_data_xfer() I added, the code can be
merged into ata_sff_data_xfer() of libata-sff.c easily. Moving the
code there is trivial if necessary.

Another problem should be addressed: using flags v.s. using data_width
member. I add a bit to indicate 8 bit mode, but this seems to be a problem
for future 32 bit I/O support in libata.

WARNING: multiple messages have this Message-ID (diff)
From: Wang Jian <lark@linux.net.cn>
To: benh@kernel.crashing.org
Cc: linuxppc-dev@ozlabs.org, Tejun Heo <htejun@gmail.com>,
	linux-ide@vger.kernel.org
Subject: Re: [PATCH RFC] pata_platform: add 8 bit data io support
Date: Sun, 12 Oct 2008 10:19:41 +0800	[thread overview]
Message-ID: <48F15EBD.4040807@linux.net.cn> (raw)
In-Reply-To: <1223763687.8157.178.camel@pasglop>

Benjamin Herrenschmidt 写道:
> On Sun, 2008-10-12 at 02:00 +0800, Wang Jian wrote:
>> To avoid adding another rare used ata_port member, new bit is added to
>> ata_port->flags.
>>
>> Originally, I hacked pata_platform to make it 8bit only to support 8bit
>> data wired CF card. This patch is more generic.
>>
>> With this patch, __pata_platform_probe() interface is changed, and
>> pata_of_platform is broken, so a small patch is needed.
>>
>> Signed-off-by: Wang Jian <lark@linux.net.cn>
>> ---
> 
> A couple of things. First I would personally prefer (but I'm not the
> libata maintainer so it's up to Jeff ...) if you had a separate patch
> that adds the 8-bit support to libata core first, and then a patch that
> modifies pata_platform.

I will do that if my 8-bit mode patch is done right technically.

> 
> Then, in order to avoid breaking bisection, I would like you to fixup
> pata_of_platform in the same patch that modifies __pata_platform_probe
> so there is no breakage in between patches.

Yes.

> 
> Now, regarding the patch itself, if the core grows a 8-bit flag, then
> I strongly suspect the core should also grow the 8-bit xfer function
> rather than having it hidden in pata_platform.

This is the main reason I send a single RFC patch. Where to add 8-bit
mode should be decided first.

Because 8-bit mode is mostly used for embedded devices, my opinion is
8-bit mode in pata_platform is enough.

However, look at pata_platform_data_xfer() I added, the code can be
merged into ata_sff_data_xfer() of libata-sff.c easily. Moving the
code there is trivial if necessary.

Another problem should be addressed: using flags v.s. using data_width
member. I add a bit to indicate 8 bit mode, but this seems to be a problem
for future 32 bit I/O support in libata.

  reply	other threads:[~2008-10-12  2:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-11 18:00 [PATCH RFC] pata_platform: add 8 bit data io support Wang Jian
2008-10-11 22:21 ` Benjamin Herrenschmidt
2008-10-11 22:21   ` Benjamin Herrenschmidt
2008-10-12  2:19   ` Wang Jian [this message]
2008-10-12  2:19     ` Wang Jian
2008-10-13  7:17 ` Tejun Heo
2008-10-13  8:04   ` Wang Jian
2008-10-13  8:25     ` Tejun Heo
2008-10-13  8:25       ` Tejun Heo
2008-10-13 14:29   ` Alan Cox
2008-10-13 14:29     ` Alan Cox

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=48F15EBD.4040807@linux.net.cn \
    --to=lark@linux.net.cn \
    --cc=benh@kernel.crashing.org \
    --cc=htejun@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.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.