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
next prev parent 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).