All of lore.kernel.org
 help / color / mirror / Atom feed
From: William R Sowerbutts <will@sowerbutts.com>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: Finn Thain <fthain@linux-m68k.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	linux-m68k <linux-m68k@lists.linux-m68k.org>,
	Richard Zidlicky <rz@linux-m68k.org>
Subject: Re: Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time
Date: Mon, 14 Aug 2023 12:18:44 +0100	[thread overview]
Message-ID: <ZNoNlC5fhztMFBAk@sowerbutts.com> (raw)
In-Reply-To: <c8fd631b-226c-4c60-884b-2ffa6437d03f@gmail.com>

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

On Mon, Aug 14, 2023 at 10:54:54AM +1200, Michael Schmitz wrote:
>On 14/08/23 10:24, William R Sowerbutts wrote:
>> * 6.4.10 + Michael's RFC patch -- IDE fails (no crash, but "Bad IO 
>> access")
>
>That might be fixed by my second RFC patch, just gone out today.

6.4.10 + your "RFC v2" patch boots without the "Bad IO access" errors!

Your patch looks correct to me.

>This one still byte-swaps the data from disk though. I understood that was
>always the case for Q40, but I may have been mistaken there.

It is indeed returning byte-swapped data.  This is easily fixed, I'm using
the attached patch.

>> For my 6.4 patch I enabled byte swapping in the pata_falcon_data_xfer()
>> function -- this allows me to use an IDE drive with everything in the
>> normal/compatible byte ordering, which makes life much easier. I assume this
>> is the intended behaviour.
>That would be the sane behaviour, but the designers of both the Falcon and
>apparently the TiVo decided otherwise, wired up the IDE data bus byte-swapped
>and saved the byteswap operations in the driver. I'm unsure how this was
>intended to work on Q40.

The Q40 does NOT have hardware to reverse the byte-swapping.  The CPU has to 
byte-swap data if you want to use disks with standard/compatible data.

>Now the question is how data on legacy Q40 IDE disks have been stored. If
>it's byte-swapped, we'd better keep that byte order in the current driver
>(meaning your changes to pata_falcon_data_xfer() won't be needed, but you
>would have to swap back data on your disk). If it's always been in PC
>compatible byte order, all data (not just the identify data) must be swapped.
>
>I'd like to have Richard's opinion on this (or hear from any other former Q40
>user).

I have learned that the "standard" firmware for the Q40, SMSQ/E, does not 
byte-swap data (it also uses an obscure partition scheme and filesystem).

Personally, I am strongly in favour of Linux on the Q40 using standard 
byte-order disks that are compatible with other machines. This feels like the 
right thing to do and it is what I think most users would expect.

Users (if there are any!) with legacy byte-swapped disks can always use the 
standard tools to byte swap them into the correct, compatible format.

Thanks

Will

_________________________________________________________________________
William R Sowerbutts                                  will@sowerbutts.com
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> ^#X@#@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  


[-- Attachment #2: pata_falcon-q40-byteswap.patch --]
[-- Type: text/x-diff, Size: 431 bytes --]

--- linux-6.4.10+michael-rfc2/drivers/ata/pata_falcon.c.orig	2023-08-14 11:21:48.636681174 +0100
+++ linux-6.4.10+michael-rfc2/drivers/ata/pata_falcon.c	2023-08-14 11:34:17.244301035 +0100
@@ -48,7 +48,7 @@
 	struct scsi_cmnd *cmd = qc->scsicmd;
 	bool swap = 1;
 
-	if (dev->class == ATA_DEV_ATA && cmd &&
+	if (!MACH_IS_Q40 && dev->class == ATA_DEV_ATA && cmd &&
 	    !blk_rq_is_passthrough(scsi_cmd_to_rq(cmd)))
 		swap = 0;
 

  parent reply	other threads:[~2023-08-14 11:19 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <ZLvZmVfzJNHlPTlJ@sowerbutts.com>
2023-07-23  8:35 ` Linux 6.4.4 on m68k - Q40 - pata_falcon causes oops at boot time Geert Uytterhoeven
2023-07-23  9:59   ` Finn Thain
2023-07-23 15:28     ` William R Sowerbutts
2023-07-24  1:43       ` Finn Thain
2023-07-24 11:09         ` William R Sowerbutts
2023-07-26  7:22           ` Finn Thain
2023-07-23 20:26     ` Michael Schmitz
2023-07-24 11:42       ` William R Sowerbutts
2023-07-24 20:26         ` Michael Schmitz
2023-07-26  9:22           ` Finn Thain
2023-07-26 20:13             ` Michael Schmitz
2023-07-27  1:16               ` Finn Thain
2023-07-27  3:17                 ` Michael Schmitz
2023-07-27 23:47                   ` Finn Thain
2023-07-28  7:21                     ` Geert Uytterhoeven
2023-07-28  7:52                     ` Michael Schmitz
2023-07-28  8:03                       ` Geert Uytterhoeven
2023-07-29  4:56                         ` Michael Schmitz
2023-08-13  3:06                     ` Michael Schmitz
2023-08-13  7:38                       ` Finn Thain
2023-08-13 21:20                         ` Michael Schmitz
2023-08-13 22:24                         ` William R Sowerbutts
2023-08-13 22:54                           ` Michael Schmitz
2023-08-13 23:37                             ` Finn Thain
2023-08-14  0:33                               ` Michael Schmitz
2023-08-14  1:15                                 ` Finn Thain
2023-08-14  2:48                                   ` Michael Schmitz
2023-08-14 11:18                             ` William R Sowerbutts [this message]
2023-08-14 20:15                               ` Michael Schmitz
2023-08-14 20:24                                 ` Richard Z
2023-08-14 23:31                                   ` Finn Thain
2023-08-15  3:05                                     ` Richard Z
2023-08-15  3:30                                       ` Michael Schmitz
2023-08-15  9:49                                         ` William R Sowerbutts
2023-08-15 10:42                                           ` Geert Uytterhoeven
2023-08-15 20:43                                             ` Richard Z
2023-08-15 20:13                                           ` Michael Schmitz
2023-08-15 22:10                                             ` William R Sowerbutts
2023-08-15 22:38                                               ` Michael Schmitz
2023-08-14 20:19                               ` Richard Z
2023-08-14 21:22                                 ` Michael Schmitz
2023-08-15 11:04                                   ` William R Sowerbutts
2023-08-16 17:56                           ` William R Sowerbutts
2023-07-27  7:18               ` Geert Uytterhoeven

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=ZNoNlC5fhztMFBAk@sowerbutts.com \
    --to=will@sowerbutts.com \
    --cc=fthain@linux-m68k.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=rz@linux-m68k.org \
    --cc=schmitzmic@gmail.com \
    /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.