[PATCH] 2.5.14 IDE 55

[PATCH] 2.5.14 IDE 55

[Martin Dalecki]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

Sun May  5 16:34:59 CEST 2002 ide-clean-55

Resync with 2.5.14.

- Update HPT374 driver carried over from 2.4.xx series by Andrew Morton.
   Resync it with the recent host chip driver changes, or better the
   introduction of an API at all.

- Consolidate the handling of device ID byte order in one place.
   This was spotted and patched by Bartomiej onierkiewicz.

- Eliminate CONFIG_BLK_DEV_IDEPCI - it's duplicating the functionality of the
   already present and fine CONFIG_PCI flag and if we are a PCI host, we are
   indeed very likely to need host chip support anyway.

- Remove some redundant info about the model and channel number from
   /proc/ide. Remove the binary entries not helpful to the user, and not used
   by any program and redundant to corresponding ioctls.

- Properly return udma_read and udma_write values in taskfile.

- Only initialize XXX_udma to the default handlers if it has not been
   initialized by the host chip initialization.

I have enabled spin lock debugging and can see that on device
flush the spin locks get wrong counts... no problems elsewher ethus
far. I will re check them next time around.

[-- Attachment #2: ide-clean-55.diff.gz --]
[-- Type: application/x-gzip, Size: 20887 bytes --]

Re: [PATCH] 2.5.14 IDE 55

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 705 bytes --]

On Mon, 6 May 2002, Martin Dalecki wrote:

> - Remove some redundant info about the model and channel number from
>    /proc/ide. Remove the binary entries not helpful to the user, and not used
>    by any program and redundant to corresponding ioctls.

Martin, how do you know it isn't used by any program?

changing /proc stuff 'becouse it's availabe elsewhere' is not a good idea,
people writing shell scripts do not nessasarily have access to ioctls.

you must have missed the proc wars of past kernels, but in general it's
not a good idea to tinker with anything in /proc unless it is a
significant improvement and 'redundant to corresponding ioctls' is not a
significant improvement.

David Lang




[-- Attachment #2: Type: APPLICATION/X-GZIP, Size: 20887 bytes --]

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Mon, 6 May 2002, Martin Dalecki wrote:

> - Eliminate CONFIG_BLK_DEV_IDEPCI - it's duplicating the functionality of the
>    already present and fine CONFIG_PCI flag and if we are a PCI host, we are
>    indeed very likely to need host chip support anyway.

Please don't do this! There are configurations possible with pci enabled 
but without a pci ide adapter.

Could you please try to compile without CONFIG_BLK_DEV_IDEDMA_PCI enabled?

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Mon, 6 May 2002, Martin Dalecki wrote:

> - Consolidate the handling of device ID byte order in one place.
>    This was spotted and patched by Bartomiej onierkiewicz.

Another thing: where is the equivalilent part of this removed code?

-static __inline__ void ide_fix_driveid(struct hd_driveid *id)
-{
-#if defined(CONFIG_AMIGA) || defined (CONFIG_MAC) || defined(M68K_IDE_SWAPW)
-   u_char *p = (u_char *)id;
-   int i, j, cnt;
-   u_char t;
-
-   if (!MACH_IS_AMIGA && !MACH_IS_MAC && !MACH_IS_Q40 && !MACH_IS_ATARI)
-       return;
-#ifdef M68K_IDE_SWAPW
-   if (M68K_IDE_SWAPW)    /* fix bus byteorder first */
-      for (i=0; i < 512; i+=2) {
-        t = p[i]; p[i] = p[i+1]; p[i+1] = t;
-      }
-#endif

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Roman Zippel napisa?:
> Hi,
> 
> On Mon, 6 May 2002, Martin Dalecki wrote:
> 
> 
>>- Eliminate CONFIG_BLK_DEV_IDEPCI - it's duplicating the functionality of the
>>   already present and fine CONFIG_PCI flag and if we are a PCI host, we are
>>   indeed very likely to need host chip support anyway.
> 
> 
> Please don't do this! There are configurations possible with pci enabled 
> but without a pci ide adapter.

So please just don't configure any PCI host chip support there.

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Roman Zippel napisa?:
> Hi,
> 
> On Mon, 6 May 2002, Martin Dalecki wrote:
> 
> 
>>- Consolidate the handling of device ID byte order in one place.
>>   This was spotted and patched by Bartomiej onierkiewicz.
> 
> 
> Another thing: where is the equivalilent part of this removed code?

Look closer it's there in ide-probe.c.

> 
> -static __inline__ void ide_fix_driveid(struct hd_driveid *id)
> -{
> -#if defined(CONFIG_AMIGA) || defined (CONFIG_MAC) || defined(M68K_IDE_SWAPW)
> -   u_char *p = (u_char *)id;
> -   int i, j, cnt;
> -   u_char t;
> -
> -   if (!MACH_IS_AMIGA && !MACH_IS_MAC && !MACH_IS_Q40 && !MACH_IS_ATARI)
> -       return;
> -#ifdef M68K_IDE_SWAPW
> -   if (M68K_IDE_SWAPW)    /* fix bus byteorder first */
> -      for (i=0; i < 512; i+=2) {
> -        t = p[i]; p[i] = p[i+1]; p[i+1] = t;
> -      }
> -#endif
> 
> bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Roman Zippel napisa?:
> Hi,
> 
> On Tue, 7 May 2002, Martin Dalecki wrote:
> 
> 
>>>Please don't do this! There are configurations possible with pci enabled 
>>>but without a pci ide adapter.
>>
>>So please just don't configure any PCI host chip support there.
> 
> 
> Then ide-pci.c is still compiled into the kernel. Why?


Becouse the big tables there are subject to go.

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Martin Dalecki napisa?:
> Uz.ytkownik Roman Zippel napisa?:
> 
>> Hi,
>>
>> On Tue, 7 May 2002, Martin Dalecki wrote:
>>
>>
>>>> Please don't do this! There are configurations possible with pci 
>>>> enabled but without a pci ide adapter.
>>>
>>>
>>> So please just don't configure any PCI host chip support there.
>>
>>
>>
>> Then ide-pci.c is still compiled into the kernel. Why?
> 
> 
> 
> Becouse the big tables there are subject to go.

And at some point in time it will check whatever there is
request for any host chip support.

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Roman Zippel napisa?:
> Hi,
> 
> On Tue, 7 May 2002, Martin Dalecki wrote:
> 
> 
>>>Another thing: where is the equivalilent part of this removed code?
>>
>>Look closer it's there in ide-probe.c.
> 
> 
> Does it still take the correct byte swapping into account?
> Did you consider using a table for the fixup? It's nothing perfomance
> critical and this might generate more compact code.


Well right now we have two different reimplementation of
get device id code, so this areas is subject to change anyway.
BTW.> It should indeed take both in to account as far as I can
see.(Despite the fact that I could affort an ATARI I hardly
can find one...)

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Roman Zippel napisa?:
> Hi,
> 
> On Tue, 7 May 2002, Martin Dalecki wrote:
> 
> 
>>>>Then ide-pci.c is still compiled into the kernel. Why?
>>>
>>>Becouse the big tables there are subject to go.
>>
>>And at some point in time it will check whatever there is
>>request for any host chip support.
> 
> 
> Could you please then do the above change _after_ you have done this?

Well one question renames: Please name me one PCI based architecture
which contains IDE support and does not contain any special host chip
attached to the very same PCI bus as well.

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Martin Dalecki wrote:

> > Please don't do this! There are configurations possible with pci enabled 
> > but without a pci ide adapter.
> 
> So please just don't configure any PCI host chip support there.

Then ide-pci.c is still compiled into the kernel. Why?

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Użytkownik Andrey Panin napisał:
> On ???, ??? 07, 2002 at 01:19:02 +0200, Martin Dalecki wrote:

>>Well one question renames: Please name me one PCI based architecture
>>which contains IDE support and does not contain any special host chip
>>attached to the very same PCI bus as well.
> 
> 
> SiS 496/497 PCI chipset for i486's. It has integrated IDE controller,
> but this controller is not connected to PCI bus.

OK - That actually is an argument I follow. Thank you I will adjust
the code. (Not quite right jet maybe but I will do it.)

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Martin Dalecki wrote:

> > Another thing: where is the equivalilent part of this removed code?
> 
> Look closer it's there in ide-probe.c.

Does it still take the correct byte swapping into account?
Did you consider using a table for the fixup? It's nothing perfomance
critical and this might generate more compact code.

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Martin Dalecki wrote:

> >> Then ide-pci.c is still compiled into the kernel. Why?
> > 
> > Becouse the big tables there are subject to go.
> 
> And at some point in time it will check whatever there is
> request for any host chip support.

Could you please then do the above change _after_ you have done this?

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Martin Dalecki wrote:

> Well one question renames: Please name me one PCI based architecture
> which contains IDE support and does not contain any special host chip
> attached to the very same PCI bus as well.

Architectures which are not directly PCI based, but which can have have 
PCI bridges. On the other hand even on PCI based archs you don't
necessarily want to compile in ide support automatically, please leave
that to Eric's autoconf.

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Andrey Panin]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Втр, Май 07, 2002 at 01:19:02 +0200, Martin Dalecki wrote:
> Uz.ytkownik Roman Zippel napisa?:
> >Hi,
> >
> >On Tue, 7 May 2002, Martin Dalecki wrote:
> >
> >
> >>>>Then ide-pci.c is still compiled into the kernel. Why?
> >>>
> >>>Becouse the big tables there are subject to go.
> >>
> >>And at some point in time it will check whatever there is
> >>request for any host chip support.
> >
> >
> >Could you please then do the above change _after_ you have done this?
> 
> Well one question renames: Please name me one PCI based architecture
> which contains IDE support and does not contain any special host chip
> attached to the very same PCI bus as well.

SiS 496/497 PCI chipset for i486's. It has integrated IDE controller,
but this controller is not connected to PCI bus.

-- 
Andrey Panin            | Embedded systems software engineer
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH] 2.5.14 IDE 55

[Dave Jones]

On Tue, May 07, 2002 at 01:19:02PM +0200, Martin Dalecki wrote:
 > Well one question renames: Please name me one PCI based architecture
 > which contains IDE support and does not contain any special host chip
 > attached to the very same PCI bus as well.

If by 'attached' you mean integrated into chipset, I have several such machines
that have no IDE without an extra add-on card.

My quad ppro has two PCI buses, but no IDE controller.
My PCI 486 has no onboard IDE.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH] 2.5.14 IDE 55

[Roman Zippel]

Hi,

On Tue, 7 May 2002, Martin Dalecki wrote:

> BTW.> It should indeed take both in to account as far as I can
> see.(Despite the fact that I could affort an ATARI I hardly
> can find one...)

That's not necessary, but I'm only afraid that functionality gets lost,
which isn't needed on the latest hardware.

bye, Roman

Re: [PATCH] 2.5.14 IDE 55

[Martin Dalecki]

Uz.ytkownik Bartlomiej Zolnierkiewicz napisa?:
> On Tue, 7 May 2002, Roman Zippel wrote:
> 
>>>BTW.> It should indeed take both in to account as far as I can
>>>see.(Despite the fact that I could affort an ATARI I hardly
>>>can find one...)
>>
>>That's not necessary, but I'm only afraid that functionality gets lost,
>>which isn't needed on the latest hardware.
>>
>>bye, Roman
> 
> 
> we should fix atari byte-swapped ide in ata_read() like we do in
> atapi_read() then ide_fix_driveid() will make rest...
> (or I am missing something?)


And the you can move this whole crap out away from
the main code by using the same method as the cris architecture
is using right now. BTW> The only thing missing is
the fact that there are currently two different
functions reading the id information there.

Re: [PATCH] 2.5.14 IDE 55

[Bartlomiej Zolnierkiewicz]

On Tue, 7 May 2002, Roman Zippel wrote:
>
> > BTW.> It should indeed take both in to account as far as I can
> > see.(Despite the fact that I could affort an ATARI I hardly
> > can find one...)
>
> That's not necessary, but I'm only afraid that functionality gets lost,
> which isn't needed on the latest hardware.
>
> bye, Roman

we should fix atari byte-swapped ide in ata_read() like we do in
atapi_read() then ide_fix_driveid() will make rest...
(or I am missing something?)

--
bkz

Re: [PATCH] 2.5.14 IDE 55

[Geert Uytterhoeven]

On Tue, 7 May 2002, Bartlomiej Zolnierkiewicz wrote:
> On Tue, 7 May 2002, Roman Zippel wrote:
> > > BTW.> It should indeed take both in to account as far as I can
> > > see.(Despite the fact that I could affort an ATARI I hardly
> > > can find one...)
> >
> > That's not necessary, but I'm only afraid that functionality gets lost,
> > which isn't needed on the latest hardware.
> >
> > bye, Roman
> 
> we should fix atari byte-swapped ide in ata_read() like we do in
> atapi_read() then ide_fix_driveid() will make rest...
> (or I am missing something?)

Here you can mix two different issues:
  - Ataris have a byte-swapped IDE interface. Hence we need support to swap
    data for interoperability (not only on Atari: imagine an Atari disk
    connected to a PC)
  - IDE is little endian, so the drive identification is little endian too.
    To make things more complex, not only multibyte objects, but also text
    strings are byteswapped.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [PATCH] 2.5.14 IDE 55

[Bartlomiej Zolnierkiewicz]

>> we should fix atari byte-swapped ide in ata_read() like we do in
>> atapi_read() then ide_fix_driveid() will make rest...
>> (or I am missing something?)
>
> Here you can mix two different issues:
>  - Ataris have a byte-swapped IDE interface. Hence we need support to
>    swap data for interoperability (not only on Atari: imagine an Atari disk
>    connected to a PC)

dealt in (arch/parameter) specific ata_read()
reverses byteswapped data

>  - IDE is little endian, so the drive identification is little endian too.
>    To make things more complex, not only multibyte objects, but also
>    text strings are byteswapped.

dealt in generic ide_fix_driveid()
converts driveid to cpu endianness

greetings...
--
bkz