Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

Hi Finn, thanks for your review! Am 04.03.2018 um 15:55 schrieb Finn Thain: > On Sun, 4 Mar 2018, Michael Schmitz wrote: > >> From: Michael Schmitz >> >> New combined SCSI driver for all ESP based Zorro SCSI boards for >> m68k Amiga. >> > > Nice work! > > Shouldn't both

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

On Sun, 4 Mar 2018, Michael Schmitz wrote: > Am 04.03.2018 um 15:55 schrieb Finn Thain: > >> +/* zorro_esp.c: ESP front-end for Amiga ZORRO SCSI systems. > >> + * > >> + * Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk) > >> + * > >> + * Copyright (C) 2011,2018 Michael Schmitz

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

Hi Finn, >> +/* zorro_esp.c: ESP front-end for Amiga ZORRO SCSI systems. >> + * >> + * Copyright (C) 1996 Jesper Skov (js...@cygnus.co.uk) >> + * >> + * Copyright (C) 2011,2018 Michael Schmitz (schm...@debian.org) for >> + * migration to ESP SCSI core > > You can blame me for some

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

Hi Finn, On Mon, Mar 5, 2018 at 2:01 PM, Finn Thain wrote: > On Mon, 5 Mar 2018, Michael Schmitz wrote: > >> >> +fail_unmap_dma_regs: >> >> + if (ioaddr > 0xff) >> >> + iounmap(esp->dma_regs); >> > >> > I think you need to test for

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

On Mon, 5 Mar 2018, Michael Schmitz wrote: > > The TCQ issue showed up on the AV Quadras becasue mac_esp doesn't know > > how to do PDMA or DMA on that hardware, and so it always uses PIO. It > > sounds like this bug would show up too given the right kind of target. > > If so, I will need to

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

On Mon, 5 Mar 2018, Michael Schmitz wrote: > All Zorro-3 boards have to have both their regs and dma_regs remapped. > I see. > What's confusing is that there is only a single Zorro-3 board currently > supported by the driver. Others will be added and I"ll use a switch > statement to pick the

[RFC] m68k: Fix dead code in bus_error030()

The only sensible place for the !(mmusr & MMU_I) test is inside the (mmusr & (MMU_I | MMU_WP)) branch. It is redundant when used in the else branch. Moreover, when used in the else branch it defeats the remaining conditionals. Hence the (mmusr & (MMU_B|MMU_L|MMU_S)) branch is unreachable, along

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

Hi Finn, >> >> +#define ZORRO_ESP_GET_PRIV(esp) ((struct zorro_esp_priv *) \ >> >> + _esp_private_data[(esp->host->host_no)]) >> >> + >> > >> > How do you know that host_no won't exceed the array bounds? >> > Why not use dev_{set,get}_drvdata(esp->dev)? -- much as mac_esp

Re: [PATCH 2/2] m68k/amiga - Zorro ESP: new zorro_esp.c

On Mon, 5 Mar 2018, Michael Schmitz wrote: > >> +fail_unmap_dma_regs: > >> + if (ioaddr > 0xff) > >> + iounmap(esp->dma_regs); > > > > I think you need to test for ZORRO_PROD_PHASE5_BLIZZARD_1230_IV_1260 here? > > On second thought - no, I don't. the ID check above only

Re: [RFC] m68k: Fix dead code in bus_error030()

Hi Finn, makes sense, unless that else_if branch was meant to follow the if (do_page_fault (>ptregs, addr, errorcode) < 0) (which it clearly doesn't, and this code hasn't changed since 2.4.30 at least. The net effect would be the same as after your patch.). Worth a try IMO. About evading a