M68k IDE updates
diff mbox series

Message ID 200304131306.h3DD6XQ3001331@callisto.of.borg
State New, archived
Headers show
Series
  • M68k IDE updates
Related show

Commit Message

Geert Uytterhoeven April 13, 2003, 1:06 p.m. UTC
M68k IDE updates: Add m68k-isms to the generic ide_fix_driveid()


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Comments

Alan Cox April 13, 2003, 2:10 p.m. UTC | #1
On Sul, 2003-04-13 at 14:06, Geert Uytterhoeven wrote:
> +#ifdef M68K_IDE_SWAPW
> +	if (M68K_IDE_SWAPW) {	/* fix bus byteorder first */
> +		u_char *p = (u_char *)id;
> +		u_char t;
> +		for (i = 0; i < 512; i += 2) {
> +			t = p[i];
> +			p[i] = p[i+1];
> +			p[i+1] = t;
> +		}
> +	}
> +#endif

This looks the wrong place to fix this problem Geert. The PPC 
folks have the same issues with byte order on busses but you
won't see ifdefs in the core IDE code for it.

Fix your __ide_mm_insw/ide_mm_outsw macros and the rest happens
automatically.

Linus, until better justification of why this has to be here
can you not apply this change.

Alan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Paul Mackerras April 13, 2003, 11:43 p.m. UTC | #2
Alan Cox writes:

> This looks the wrong place to fix this problem Geert. The PPC 
> folks have the same issues with byte order on busses but you
> won't see ifdefs in the core IDE code for it.
> 
> Fix your __ide_mm_insw/ide_mm_outsw macros and the rest happens
> automatically.

As I understand it, on some platforms (including some PPC platforms,
but not powermacs) one needs to byteswap drive ID data but not the
normal sector data.  Or vice versa.  Whether drive ID data needs
byte-swapping comes down to how the drive is attached to the bus.  The
conventions used by other systems that we need to interoperate with
(e.g. other OSes, or just older kernels) determine whether normal
sector data needs byte-swapping or not.

Since __ide_mm_insw doesn't get told whether it is transferring normal
sector data or drive ID data, it can't necessarily do the right thing
in both situations.

It's very possible that there are some PPC platforms for which IDE is
borken right now - I strongly suspect this would be the case for the
Tivo at least, and probably several other embedded PPC platforms.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 14, 2003, 8:39 a.m. UTC | #3
On Mon, 14 Apr 2003, Paul Mackerras wrote:
> Alan Cox writes:
> > This looks the wrong place to fix this problem Geert. The PPC 
> > folks have the same issues with byte order on busses but you
> > won't see ifdefs in the core IDE code for it.
> > 
> > Fix your __ide_mm_insw/ide_mm_outsw macros and the rest happens
> > automatically.
> 
> As I understand it, on some platforms (including some PPC platforms,
> but not powermacs) one needs to byteswap drive ID data but not the
> normal sector data.  Or vice versa.  Whether drive ID data needs
> byte-swapping comes down to how the drive is attached to the bus.  The
> conventions used by other systems that we need to interoperate with
> (e.g. other OSes, or just older kernels) determine whether normal
> sector data needs byte-swapping or not.
> 
> Since __ide_mm_insw doesn't get told whether it is transferring normal
> sector data or drive ID data, it can't necessarily do the right thing
> in both situations.

Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
on-disk data to be that way, for compatibility with e.g. TOS.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Benjamin Herrenschmidt April 14, 2003, 9:19 a.m. UTC | #4
On Mon, 2003-04-14 at 10:39, Geert Uytterhoeven wrote:

> Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> on-disk data to be that way, for compatibility with e.g. TOS.

Some designers need to be shot...

What about optionally making fix_drive_id a platoform hook
(like it was, but with a reasonable default) to avoid clobbering
the common code with those #ifdefs ?

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 14, 2003, 9:24 a.m. UTC | #5
On 14 Apr 2003, Benjamin Herrenschmidt wrote:
> On Mon, 2003-04-14 at 10:39, Geert Uytterhoeven wrote:
> 
> > Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> > on-disk data to be that way, for compatibility with e.g. TOS.
> 
> Some designers need to be shot...
> 
> What about optionally making fix_drive_id a platoform hook
> (like it was, but with a reasonable default) to avoid clobbering
> the common code with those #ifdefs ?

Yes, I already suggested that in my IDE patch for 2.4.x. But I was in a hurry,
since I wanted to get m68k IDE working in 2.4.21.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 14, 2003, 12:19 p.m. UTC | #6
On Llu, 2003-04-14 at 10:24, Geert Uytterhoeven wrote:
> > What about optionally making fix_drive_id a platoform hook
> > (like it was, but with a reasonable default) to avoid clobbering
> > the common code with those #ifdefs ?
> 
> Yes, I already suggested that in my IDE patch for 2.4.x. But I was in a hurry,
> since I wanted to get m68k IDE working in 2.4.21.

The base kernel is not an appropriate place for hurrying. Lets fix this properly
even if it takes a bit of time


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 14, 2003, 12:21 p.m. UTC | #7
On Llu, 2003-04-14 at 09:39, Geert Uytterhoeven wrote:
> Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> on-disk data to be that way, for compatibility with e.g. TOS.

That is a higher level problem. You need a byteswap mode for the loop device
it seems. Then you can read atari disks on any box..


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 14, 2003, 12:48 p.m. UTC | #8
On Llu, 2003-04-14 at 00:43, Paul Mackerras wrote:
> Since __ide_mm_insw doesn't get told whether it is transferring normal
> sector data or drive ID data, it can't necessarily do the right thing
> in both situations.

That may be the right change to make.

> It's very possible that there are some PPC platforms for which IDE is
> borken right now - I strongly suspect this would be the case for the
> Tivo at least, and probably several other embedded PPC platforms.

For the older tivo that would be sad, for the newer tivo where they
digitally sign the binary and don't provide the signatures -- too bad
they are violating the license clarifications on the IDE code if they
use it.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 14, 2003, 12:48 p.m. UTC | #9
On Llu, 2003-04-14 at 00:43, Paul Mackerras wrote:
> Since __ide_mm_insw doesn't get told whether it is transferring normal
> sector data or drive ID data, it can't necessarily do the right thing
> in both situations.

That may be the right change to make.

> It's very possible that there are some PPC platforms for which IDE is
> borken right now - I strongly suspect this would be the case for the
> Tivo at least, and probably several other embedded PPC platforms.

For the older tivo that would be sad, for the newer tivo where they
digitally sign the binary and don't provide the signatures -- too bad
they are violating the license clarifications on the IDE code if they
use it.

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 14, 2003, 1:44 p.m. UTC | #10
On 14 Apr 2003, Alan Cox wrote:
> On Llu, 2003-04-14 at 09:39, Geert Uytterhoeven wrote:
> > Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> > on-disk data to be that way, for compatibility with e.g. TOS.
> 
> That is a higher level problem. You need a byteswap mode for the loop device
> it seems. Then you can read atari disks on any box..

You're talking about a different problem.

We want to read Atari disks on Ataris, too.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 14, 2003, 4:03 p.m. UTC | #11
On Llu, 2003-04-14 at 14:44, Geert Uytterhoeven wrote:
> On 14 Apr 2003, Alan Cox wrote:
> > On Llu, 2003-04-14 at 09:39, Geert Uytterhoeven wrote:
> > > Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> > > on-disk data to be that way, for compatibility with e.g. TOS.
> > 
> > That is a higher level problem. You need a byteswap mode for the loop device
> > it seems. Then you can read atari disks on any box..
> 
> You're talking about a different problem.
> 
> We want to read Atari disks on Ataris, too.

You can initrd a loop over ide root on the Atari. I can see reasons (performance)
you don't want to do that, and I'm quite happy for someone to split the mmio ops
for data/control to clean that up.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Linus Torvalds April 14, 2003, 5:44 p.m. UTC | #12
On Mon, 14 Apr 2003, Paul Mackerras wrote:
> 
> Since __ide_mm_insw doesn't get told whether it is transferring normal
> sector data or drive ID data, it can't necessarily do the right thing
> in both situations.

Can we please then just separate the two functions out into "fetch sector
data" and "fetch drive ID"? And NOT playing with another frigging broken
passed-down flag that people get wrong and isn't obvious what it does
anyway? It's a lot easier to do

	/* On sane architectures, data and ID are accessed the same */
	#define ide_fetch_sector_data(...) __ide_fetch_data(..)
	#define ide_fetch_id_data(...) __ide_fetch_data(..)

than it is to carry a flag around and having to remember to get it right 
in every place this is used.

It's more efficient too, but the _clarity_ and lack of dynamic flags is a 
hell of a lot more important.

And stupid architectures that may have to re-implement (and possible
duplicate) the ID fetch code only have themselves to blame. Although it 
might easily be as simple as

	/*
	 * The PCI bus is wired up the wrong way, we need to byteswap
	 * the ID results after they come back
	 */
	static inline xxx ide_fetch_id_data(...)
	{
		__ide_fetch_data(..)
		bswap_id_data(..)
	}

and please keep this in some m68k-specific file instead of forcing 
_everybody_ to know about the braindamage.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 14, 2003, 7:54 p.m. UTC | #13
On Mon, 14 Apr 2003, Linus Torvalds wrote:
> On Mon, 14 Apr 2003, Paul Mackerras wrote:
> > Since __ide_mm_insw doesn't get told whether it is transferring normal
> > sector data or drive ID data, it can't necessarily do the right thing
> > in both situations.
> 
> Can we please then just separate the two functions out into "fetch sector
> data" and "fetch drive ID"? And NOT playing with another frigging broken
> passed-down flag that people get wrong and isn't obvious what it does
> anyway? It's a lot easier to do
> 
> 	/* On sane architectures, data and ID are accessed the same */
> 	#define ide_fetch_sector_data(...) __ide_fetch_data(..)
> 	#define ide_fetch_id_data(...) __ide_fetch_data(..)
> 
> than it is to carry a flag around and having to remember to get it right 
> in every place this is used.
> 
> It's more efficient too, but the _clarity_ and lack of dynamic flags is a 
> hell of a lot more important.
> 
> And stupid architectures that may have to re-implement (and possible
> duplicate) the ID fetch code only have themselves to blame. Although it 
> might easily be as simple as
> 
> 	/*
> 	 * The PCI bus is wired up the wrong way, we need to byteswap
> 	 * the ID results after they come back
> 	 */
> 	static inline xxx ide_fetch_id_data(...)
> 	{
> 		__ide_fetch_data(..)
> 		bswap_id_data(..)
> 	}
> 
> and please keep this in some m68k-specific file instead of forcing 
> _everybody_ to know about the braindamage.

I think the least-intrusive solution is something like this:

--- linux-2.5/drivers/ide/ide-iops.c.orig	Mon Apr 14 21:43:30 2003
+++ linux-2.5/drivers/ide/ide-iops.c	Mon Apr 14 21:44:53 2003
@@ -423,8 +423,7 @@
  */
 void ide_fix_driveid (struct hd_driveid *id)
 {
-#ifndef __LITTLE_ENDIAN
-# ifdef __BIG_ENDIAN
+    if (ide_driveid_needs_swapping(id)) {
 	int i;
 	u16 *stringcast;
 
@@ -512,10 +511,7 @@
 	for (i = 0; i < 48; i++)
 		id->words206_254[i] = __le16_to_cpu(id->words206_254[i]);
 	id->integrity_word  = __le16_to_cpu(id->integrity_word);
-# else
-#  error "Please fix <asm/byteorder.h>"
-# endif
-#endif
+    }
 }
 
 EXPORT_SYMBOL(ide_fix_driveid);

Where ide_driveid_needs_swapping() is #define'd to return 0 (never swap), 1
(always swap), or whatever architecture-specific logic you need.

We can even have defaults in <linux/ide.h>

    #ifndef ide_driveid_needs_swapping
    # ifdef __LITTLE_ENDIAN
    #  define ide_driveid_needs_swapping(id)	0
    # else
    #  ifdef __BIG_ENDIAN
    #   define ide_driveid_needs_swapping(id)	1
    #  else
    #   error "Please fix <asm/byteorder.h>"
    #  endif
    # endif
    #endif

Sounds sufficiently sane?

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Paul Mackerras April 14, 2003, 10:31 p.m. UTC | #14
Geert Uytterhoeven writes:

> I think the least-intrusive solution is something like this:
> 
> --- linux-2.5/drivers/ide/ide-iops.c.orig	Mon Apr 14 21:43:30 2003
> +++ linux-2.5/drivers/ide/ide-iops.c	Mon Apr 14 21:44:53 2003
> @@ -423,8 +423,7 @@
>   */
>  void ide_fix_driveid (struct hd_driveid *id)
>  {
> -#ifndef __LITTLE_ENDIAN
> -# ifdef __BIG_ENDIAN
> +    if (ide_driveid_needs_swapping(id)) {

I really think that whether the driveid needs swapping should be
regarded as a property of the interface, not of the system as a whole.

I like the idea of adding a "read in driveid" function pointer to the
ide_hwif_t structure.  Most systems would set that to the same as the
INSW function pointer.  For those systems where the hardware designer
suffered a momentary dizzy spell we can set it to point to a function
that does the necessary byte-swapping.

Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jamie Lokier April 15, 2003, 4:45 a.m. UTC | #15
Geert Uytterhoeven wrote:
> > Since __ide_mm_insw doesn't get told whether it is transferring normal
> > sector data or drive ID data, it can't necessarily do the right thing
> > in both situations.
> 
> Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> on-disk data to be that way, for compatibility with e.g. TOS.

Isn't that best solved in the TOS filesystem code?

That way, Ataris running Linux can read ext2 disks from other systems
properly, and other systems can read TOS disks written by Ataris
properly.

Or did I miss something?

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 15, 2003, 8:11 a.m. UTC | #16
On Tue, 15 Apr 2003, Jamie Lokier wrote:
> Geert Uytterhoeven wrote:
> > > Since __ide_mm_insw doesn't get told whether it is transferring normal
> > > sector data or drive ID data, it can't necessarily do the right thing
> > > in both situations.
> > 
> > Indeed. Ataris and Q40/Q60s have byteswapped IDE busses, but they expect
> > on-disk data to be that way, for compatibility with e.g. TOS.
> 
> Isn't that best solved in the TOS filesystem code?

There's also a partition table to read. BTW, Atari uses MS-DOS style
partitioning.

> That way, Ataris running Linux can read ext2 disks from other systems
> properly, and other systems can read TOS disks written by Ataris
> properly.

That's why there's also an option to swap all diskdata at the IDE level, so you
can take your Atari disks to a PC and vice versa.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 15, 2003, 8:14 a.m. UTC | #17
On Tue, 15 Apr 2003, Paul Mackerras wrote:
> Geert Uytterhoeven writes:
> > I think the least-intrusive solution is something like this:
> > 
> > --- linux-2.5/drivers/ide/ide-iops.c.orig	Mon Apr 14 21:43:30 2003
> > +++ linux-2.5/drivers/ide/ide-iops.c	Mon Apr 14 21:44:53 2003
> > @@ -423,8 +423,7 @@
> >   */
> >  void ide_fix_driveid (struct hd_driveid *id)
> >  {
> > -#ifndef __LITTLE_ENDIAN
> > -# ifdef __BIG_ENDIAN
> > +    if (ide_driveid_needs_swapping(id)) {
> 
> I really think that whether the driveid needs swapping should be
> regarded as a property of the interface, not of the system as a whole.
> 
> I like the idea of adding a "read in driveid" function pointer to the
> ide_hwif_t structure.  Most systems would set that to the same as the
> INSW function pointer.  For those systems where the hardware designer
> suffered a momentary dizzy spell we can set it to point to a function
> that does the necessary byte-swapping.

That sounds OK to me.

But I'd like to have the actual swapping code in a common source or header
file, else we fall back to the old approach, where all platforms that needed it
implemented there own driveid swapping code, which had to be kept in sync when
more reserved fields in the driveid got an actual meaning.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Jörn Engel April 15, 2003, 9:23 a.m. UTC | #18
On Tue, 15 April 2003 10:11:37 +0200, Geert Uytterhoeven wrote:
> 
> BTW, Atari uses MS-DOS style partitioning.

Interesting. Then how do you explain this (2.5.67)
config MSDOS_PARTITION
	bool "PC BIOS (MSDOS partition tables) support" if PARTITION_ADVANCED
	default y if !PARTITION_ADVANCED && !AMIGA && !ATARI && !MAC && !SGI_IP22 && !ARM && !SGI_IP27

or this (2.4.20)
   if [ "$CONFIG_AMIGA" != "y" -a "$CONFIG_ATARI" != "y" -a \
        "$CONFIG_MAC" != "y" -a "$CONFIG_SGI_IP22" != "y" -a \
        "$CONFIG_SGI_IP27" != "y" ]; then
      define_bool CONFIG_MSDOS_PARTITION y
   fi

In both cases, CONFIG_MSDOS_PARTITION is always y, *except* for Atari
and some others. According to your comment above, that should be
changed, shouldn't it?

Jörn
Geert Uytterhoeven April 15, 2003, 9:52 a.m. UTC | #19
On Tue, 15 Apr 2003, [iso-8859-1] Jörn Engel wrote:
> On Tue, 15 April 2003 10:11:37 +0200, Geert Uytterhoeven wrote:
> > BTW, Atari uses MS-DOS style partitioning.
> 
> Interesting. Then how do you explain this (2.5.67)
> config MSDOS_PARTITION
> 	bool "PC BIOS (MSDOS partition tables) support" if PARTITION_ADVANCED
> 	default y if !PARTITION_ADVANCED && !AMIGA && !ATARI && !MAC && !SGI_IP22 && !ARM && !SGI_IP27
> 
> or this (2.4.20)
>    if [ "$CONFIG_AMIGA" != "y" -a "$CONFIG_ATARI" != "y" -a \
>         "$CONFIG_MAC" != "y" -a "$CONFIG_SGI_IP22" != "y" -a \
>         "$CONFIG_SGI_IP27" != "y" ]; then
>       define_bool CONFIG_MSDOS_PARTITION y
>    fi
> 
> In both cases, CONFIG_MSDOS_PARTITION is always y, *except* for Atari
> and some others. According to your comment above, that should be
> changed, shouldn't it?

Bummer, better check the sources first (I never had an Atari). Atari uses its
own partitioning scheme.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Geert Uytterhoeven April 21, 2003, 4:55 p.m. UTC | #20
On Mon, 14 Apr 2003, Linus Torvalds wrote:
> On Mon, 14 Apr 2003, Paul Mackerras wrote:
> > Since __ide_mm_insw doesn't get told whether it is transferring normal
> > sector data or drive ID data, it can't necessarily do the right thing
> > in both situations.
> 
> Can we please then just separate the two functions out into "fetch sector
> data" and "fetch drive ID"? And NOT playing with another frigging broken
> passed-down flag that people get wrong and isn't obvious what it does
> anyway? It's a lot easier to do
> 
> 	/* On sane architectures, data and ID are accessed the same */
> 	#define ide_fetch_sector_data(...) __ide_fetch_data(..)
> 	#define ide_fetch_id_data(...) __ide_fetch_data(..)
> 
> than it is to carry a flag around and having to remember to get it right 
> in every place this is used.

OK, I took a closer look at the IDE identification innards.

It's quite easy to call hwif->ata_input_id() instead of hwif->ata_input_data()
for reading the drive ID. Then hwif->ata_input_id() can take care of the
byteswapping for hardwired byteswapped IDE busses.

However, there's also a routine that involves more magic:
taskfile_lib_get_identify(). While trying to understand that one, I found more
commands that should call the (possible byteswapping) hwif->ata_input_id()
operations, like SMART commands. So first we need a clearer differentiation
between commands that transfer on-platter data, or other drive data.

Any comments from the IDE experts?

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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
Alan Cox April 22, 2003, 2:49 p.m. UTC | #21
On Llu, 2003-04-21 at 17:55, Geert Uytterhoeven wrote:
> However, there's also a routine that involves more magic:
> taskfile_lib_get_identify(). While trying to understand that one, I found more
> commands that should call the (possible byteswapping) hwif->ata_input_id()
> operations, like SMART commands. So first we need a clearer differentiation
> between commands that transfer on-platter data, or other drive data.
> 
> Any comments from the IDE experts?

Only one, stop abusing the IDE layer and do your byte swapping via a loopback/md 
or similar piece of code. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Patch
diff mbox series

--- linux-2.5.x/drivers/ide/ide-iops.c	Mon Sep 16 09:49:17 2002
+++ linux-m68k-2.5.x/drivers/ide/ide-iops.c	Wed Oct  2 23:01:40 2002
@@ -360,6 +360,23 @@ 
 	int i;
 	u16 *stringcast;
 
+#ifdef __mc68000__
+	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 */
+		u_char *p = (u_char *)id;
+		u_char t;
+		for (i = 0; i < 512; i += 2) {
+			t = p[i];
+			p[i] = p[i+1];
+			p[i+1] = t;
+		}
+	}
+#endif
+#endif /* __mc68000__ */
+
 	id->config         = __le16_to_cpu(id->config);
 	id->cyls           = __le16_to_cpu(id->cyls);
 	id->reserved2      = __le16_to_cpu(id->reserved2);