linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kumar Gala <galak@kernel.crashing.org>
To: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Cc: linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: RFC: Compact Flash True IDE Mode Driver
Date: Mon, 13 Feb 2006 16:13:18 -0600	[thread overview]
Message-ID: <4EAA9C9B-947B-493D-B3D9-CFA1EC0A71CA@kernel.crashing.org> (raw)
In-Reply-To: <58cb370e0602131221k60e23cffo480fbec812b6560e@mail.gmail.com>


On Feb 13, 2006, at 2:21 PM, Bartlomiej Zolnierkiewicz wrote:

> On 2/13/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>>
>> On Feb 13, 2006, at 10:53 AM, Bartlomiej Zolnierkiewicz wrote:
>>
>>> On 2/13/06, Kumar Gala <galak@kernel.crashing.org> wrote:
>>>
>>>>>> +static void cfide_outsl(unsigned long port, void *addr, u32  
>>>>>> count)
>>>>>> +{
>>>>>> +       panic("outsl unsupported");
>>>>>> +}
>>>>>
>>>>> This will panic as soon as somebody tries to enable 32-bit I/O
>>>>> using hdparm.  Please add ide_hwif_t.no_io_32bit flag and teach
>>>>> ide-disk.c:ide_disk_setup() about it (separate patch).
>>>>
>>>> I'm not sure I follow this, can you expand.
>>>
>>> Do "hdparm -c 2 /dev/hdx" first and then read/write to the device
>>> and you should see it. :)
>>>
>>> We need to make "hdparm -c 2" (and "hdparm -c 3") unsupported
>>> (see how "io_32bit" setting is handled in ide_add_generic_settings()
>>> and how it can be read-only or read-write setting depending on the
>>> value of drive->no_io_32bit).
>>>
>>> To do this we need to set drive->no_io_32bit to 1 (see how
>>> ide_disk_setup() handles it).  Unfortunately 32-bit I/O capability
>>> is based on capabilities of both host and device so we have to
>>> add new flag hwif->no_io_32bit to indicate that host doesn't
>>> support 32-bit I/O.
>>
>> This all make sense, should I check for hwif->no_io_32bit in
>> idedisk_setup() and set drive->no_io_32bit to 1 if hwif->no_io_32bit
>> is 1 or do this the test in ide_add_generic_settings()?
>
> Good question.  idedisk_setup() seems more logical but in the current
> model "io_32bit" setting is still accessible without ide-disk  
> driver through
> /proc/ide/ interface so...
>
> Moreover the current drive->no_io_32bit code in ide-disk is wrong:
> * it shouldn't be overriding drive->no_io_32bit flag if it is 1
> * doing this in ide-disk may be too late w.r.t.  
> ide_add_generic_settings()
>
> Therefore your previous suggestion is the right one - the best place
> to deal with ->no_io_32bit is ide-probe.c - doing this for all  
> drives at
> the end of probe_hwif() should fix all above issues.

Now I'm confused.  If I understand the code, what I want is for the  
"io_32bit" setting to have its RW field set to SETTING_READ, such  
that drive->no_io_32bit can NOT be changed.  Additionally, I want it  
set to 1 if hwif->no_io_32bit is 1.

Are you saying that at the end of probe_hwif() I should iterate over  
the drives for that hwif and set drive->no_io_32bit to 1 if hwif- 
 >no_io_32bit is 1?  If so, can I do this in the last loop that  
already exists that iterates over the drives?

Will I not also want to test hwif->no_io_32bit in idedisk_setup() to  
ensure that it can only set driver->no_io_32bit to 0 if hwif- 
 >no_io32bit is 0?

- kumar


  reply	other threads:[~2006-02-13 22:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-01  7:19 RFC: Compact Flash True IDE Mode Driver Kumar Gala
2006-02-06  4:13 ` Benjamin Herrenschmidt
2006-02-13 10:35 ` Bartlomiej Zolnierkiewicz
2006-02-13 16:30   ` Kumar Gala
2006-02-13 16:53     ` Bartlomiej Zolnierkiewicz
2006-02-13 19:45       ` Kumar Gala
2006-02-13 20:21         ` Bartlomiej Zolnierkiewicz
2006-02-13 22:13           ` Kumar Gala [this message]
2006-02-13 22:35             ` Bartlomiej Zolnierkiewicz
2006-02-14 14:57               ` Kumar Gala
2006-02-14 15:57                 ` Bartlomiej Zolnierkiewicz
2006-02-14 16:07                   ` Kumar Gala
2006-02-14 16:24                     ` Bartlomiej Zolnierkiewicz
2006-02-14 16:58   ` Alan Cox
2006-02-14 16:48     ` Kumar Gala

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=4EAA9C9B-947B-493D-B3D9-CFA1EC0A71CA@kernel.crashing.org \
    --to=galak@kernel.crashing.org \
    --cc=bzolnier@gmail.com \
    --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 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).