Re: [PATCH 23/29] atari_scsi: Convert to platform device

Finn, On Fri, 3 Oct 2014, Geert Uytterhoeven wrote: + if (ATARIHW_PRESENT(TT_SCSI)) { + atari_scsi_reg_read = atari_scsi_tt_reg_read; + atari_scsi_reg_write = atari_scsi_tt_reg_write; + } else if (ATARIHW_PRESENT(ST_SCSI)) { +

Re: [PATCH 23/29] atari_scsi: Convert to platform device

Hi Finn, Can these be handled through the platform_device's resources? I don't know. Should be possible - I've seen that used in the ISP116x HCD driver (arch-dependent post-register access delay function passed via platform data). Yes, possible, but is it

Re: [PATCH 23/29] atari_scsi: Convert to platform device

Hi Finn, not certain it is related to this exact patch - the driver crashes pretty much on the spot when selecting the first target on the bus. Panic log: Atari SCSI: resetting the SCSI bus... done scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 0x0, irq 0, can_queue 8,

Re: [PATCH 23/29] atari_scsi: Convert to platform device

Hi Finn, not certain it is related to this exact patch - the driver crashes pretty much on the spot when selecting the first target on the bus. If it isn't that exact patch then it will probably be one of the other atari_scsi patches. Most of the other relevant stuff was covered by my own

Re: [PATCH 23/29] atari_scsi: Convert to platform device

Finn, On Mon, 20 Oct 2014, Michael Schmitz wrote: Hi Finn, not certain it is related to this exact patch - the driver crashes pretty much on the spot when selecting the first target on the bus. If it isn't that exact patch then it will probably be one of the other atari_scsi

Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

on Sun 3, Atari ST and/or Atari TT would be nice (I don't have the hardware). Tested atari_scsi on Falcon / CT60 hardware - no regressions over v1 that I've seen. Tested-by: Michael Schmitz schmitz...@gmail.com There are old bugs relating to exception handling and autosense in the core

Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

Hi Finn, Thanks for testing. No regressions over v1 means no regressions, right? Well, what would I compare the driver performance to? With your patches to sort out locking races, the driver is more stable than I've ever seen it in years. That's a definite win. Big improvement over the

Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

David, Geert, my Falcon has some variant of this clock patch installed - it may not be precisely the one described but reasonably close. It also has one of the old 030 accelerator tricks (clock doubling of the 030 if the CPU does not do bus cycles - named Skunk) fitted; the clock patch was

Re: [PATCH v2 00/36] Fixes, cleanups and modernization for NCR5380 drivers

Hi Finn, Leaves the current instability - I did some work on the CT60 accelerator (reflashed the firmware so I can use the CTPCI board). This might have caused the system to become more unstable. Needs more investigation. I gather from the emails we've exchanged that the current instability

Re: [PATCH v2 22/36] atari_scsi: Fix atari_scsi deadlocks on Falcon

); int stdma_islocked( void ); -void *stdma_locked_by( void ); +int stdma_is_locked_by(irq_handler_t); void stdma_init( void ); /* End of Prototypes **/ Acked-by: Michael Schmitz schm...@debian.org Index: linux/drivers/scsi/atari_NCR5380.c

Re: [PATCH v2 22/36] atari_scsi: Fix atari_scsi deadlocks on Falcon

Finn, Index: linux/drivers/scsi/atari_NCR5380.c === --- linux.orig/drivers/scsi/atari_NCR5380.c 2014-10-27 16:25:36.0 +1100 +++ linux/drivers/scsi/atari_NCR5380.c 2014-10-27 16:25:45.0 +1100 @@ -879,10

Re: [PATCH 1/1] Remove of old NCR53C9x/esp family of drivers

Hi all, Anybody who can look into converting the m68k NCR53C9x drivers and has hardware to test (some of) them? I don't think we can afford losing one third of our SCSI drivers... I can look into converting some (having worked on the m68k Mac ESP driver in the past - I do recall the Mac

Re: esp_scsi QTAG in FAS216 (was Re: [PATCH 0/2] Experimental Amiga Zorro ESP driver)

, Geert Uytterhoeven wrote: On Wed, Sep 11, 2013 at 12:12 PM, Michael Schmitz schmitz...@gmail.com wrote: problem. Using PIO, only the first byte of the tag message comes through. It might not be esp_scsi's fault, but there seems to be an assumption that all devices support TCQ. Also, no SCSI-2

[PATCH 3/3] m68k/atari - atari_scsi lock fixes: punt if deadlocked

In case a SCSI command is queued from softirq context, and another driver currently holds the ST-DMA lock, tell the SCSI midlevel to hold off queueing commands for now. Something will hopefully resume play later. Signed-off-by: Michael Schmitz schm...@debian.org --- drivers/scsi/atari_NCR5380.c

[PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes

be cleared, otherwise atari_scsi_bus_reset will not release the ST-DMA lock, deadlocking further error recovery. Signed-off-by: Michael Schmitz schm...@debian.org --- drivers/scsi/atari_NCR5380.c | 29 ++--- drivers/scsi/atari_scsi.c|2 +- 2 files changed, 19 insertions

[PATCH 0/3] m68k/atari - Atari NCR5380 SCSI driver fixes (resent)

Geert, this patch series brings the Atari NCR5380 driver up to date with current 3.x (or perhaps even 2.6) series SCSI midlevel and error handling changes. The first patch fixes completion condition errors contained in Arnd Bergmann's patch ([PATCH, RFC 02/30] scsi: atari_scsi: fix sleep_on

[PATCH 1/3] m68k/atari - atari_scsi: fix wait_event completion conditions

Fix patch by ArndB changing falcon_get_lock to use wait_event. Some of the completion conditions had been missed when converting from while() {} to do {} until() logic. Signed-off-by: Michael Schmitz schm...@debian.org --- drivers/scsi/atari_scsi.c | 14 +++--- 1 files changed, 7

Re: [PATCH 00/16] sleep_on removal, second try

-pingi.de Cc: Mauro Carvalho Chehab m.che...@samsung.com Cc: Michael Schmitz schm...@biophys.uni-duesseldorf.de Cc: Peter Zijlstra pet...@infradead.org Cc: linux-atm-gene...@lists.sourceforge.net Cc: linux-me...@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: net...@vger.kernel.org Arnd Bergmann (16

Re: [PATCH 02/16] scsi: atari_scsi: fix sleep_on race

from going to sleep when no other thread holds the same lock or tries to get it, and we no longer schedule with irqs disabled. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Michael Schmitz schmitz...@gmail.com Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: James E.J. Bottomley jbottom

Re: [PATCH 02/16] scsi: atari_scsi: fix sleep_on race

Hello Arnd, On Thursday 27 February 2014, Michael Schmitz wrote: Arnd Bergmann wrote: Nack - the completion condition in the first hunk has its logic reversed. Try this instead (while() loops while condition true, do {} until () loops while condition false, no?) Sorry

[PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes

be cleared, otherwise atari_scsi_bus_reset will not release the ST-DMA lock, deadlocking further error recovery. Signed-off-by: Michael Schmitz schm...@debian.org Cc: Geert Uytterhoeven ge...@linux-m68k.org Cc: James E.J. Bottomley jbottom...@parallels.com Cc: linux-scsi@vger.kernel.org --- drivers/scsi

[PATCH 0/3] m68k Atari SCSI fixes

, Michael Schmitz [PATCH 1/3] m68k/atari - convert atari_scsi falcon_get_lock() to use wait_event() [PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes [PATCH 3/3] m68k/atari - atari_scsi: punt if deadlocked -- To unsubscribe from this list: send the line unsubscribe linux-scsi

[PATCH 1/3] m68k/atari - convert atari_scsi falcon_get_lock() to use wait_event()

no other thread holds the same lock or tries to get it, and we no longer schedule with irqs disabled. MSch: fixed completion conditions missed in Arnds' original RFC patch. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Michael Schmitz schm...@debian.org Cc: Geert Uytterhoeven ge...@linux

[PATCH 3/3] m68k/atari - atari_scsi: punt if deadlocked

In case a SCSI command is queued from softirq context, and another driver currently holds the ST-DMA lock, tell the SCSI midlevel to hold off queueing commands for now. Midlevel will resume play later. Signed-off-by: Michael Schmitz schm...@debian.org Cc: Geert Uytterhoeven ge...@linux-m68k.org

Re: [PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes

Finn, nothings' been merged yet, still pending review from the SCSI team. Comments below. This is a larger version of Michael's patch. It takes care of the header files and comments and it addresses sun3_NCR5380 as well as atari_NCR5380. This means that the initio.h include (!) can be

Re: [PATCH 2/3] m68k/atari - atari_scsi: change abort/reset return codes

Bugger - forgot to CC Sammy as well. My only comment of substance is that the reset handling doesn't need to be done the same way as on Atari, as there's no special locking to account for. Cheers, Michael Am 11.03.2014 um 21:28 schrieb Geert Uytterhoeven: CC Sammy On Tue, Mar

[PATCH v3 4/4] m68k/atari - atari_scsi: use correct virt/phys translation for DMA buffer

With the kernel running from FastRAM instead of ST-RAM, none of ST-RAM is mapped by mem_init, and DMA-addressable buffer must be mapped by ioremap. Use platform specific virt/phys translation helpers for this case. Signed-off-by: Michael Schmitz schm...@debian.org Cc: linux-scsi@vger.kernel.org

Re: esp_scsi QTAG in FAS216

Hello Dave, Tuomas, Also, looking at the timeout formulae in the old NCR53C9x.c driver, the values would be different for FAS216. Why was this dropped from the modern esp_scsi? I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in

Re: esp_scsi QTAG in FAS216

Hello Kars, I've never seen a formula for any ESP or FAS chip for the timeout other than the one mentioned in huge comment in esp_set_clock_params(), although I do see the 7668 instead of 8192 factor being used in the old NCR53C9x driver. I haven't gone far enough back in the 53C9x

Re: esp_scsi QTAG in FAS216

Hi Kars, thanks for the PDFs! Bit 2 SCSI-2 Setting this bit allows the FSC to support two new features adopted in SCSI-2: the 3-byte message exchange for Tagged-Queueing and Group 2 commands. These features can also be set independently in the Config 3 register. Tagged-Queueing When

Re: esp_scsi QTAG in FAS216

reselection on all esp100a and later chips. Reported-by: Kars de Jong jo...@linux-m68k.org Reported-by: Michael Schmitz schmitz...@gmail.com Signed-off-by: David S. Miller da...@davemloft.net diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c index 55548dc..16f69e0 100644 --- a/drivers

Re: esp_scsi QTAG in FAS216

. This should allow proper recognition of 3 byte reselection on all esp100a and later chips. Reported-by: Kars de Jong jo...@linux-m68k.org Reported-by: Michael Schmitz schmitz...@gmail.com Signed-off-by: David S. Miller da...@davemloft.net diff --git a/drivers/scsi/esp_scsi.c b/drivers/scsi/esp_scsi.c

Re: [PATCH v2 07/12] scsi/NCR5380: adopt NCR5380_dprint() and NCR5380_dprint_phase()

Acked-by: Michael Schmitz schm...@debian.org All NCR5380 drivers already include the NCR5380.h header. Better to adopt those macros rather than have three variations on them. Moreover, the macros in NCR5380.h are preferable anyway: the atari_NCR5380 and sun3_NCR5380 versions are inflexible

Re: [PATCH v2 08/12] scsi/NCR5380: adopt dprintk()

Acked-by: Michael Schmitz schm...@debian.org All NCR5380 drivers already include the NCR5380.h header. Better to adopt those macros rather than have three variations on them. Moreover, the macros in NCR5380.h are preferable because the atari_NCR5380 and sun3_NCR5380 versions are inflexible

Re: [PATCH v2 10/12] scsi/NCR5380: remove unused macro definitions

Acked-by: MIchael Schmitz schm...@debian.org Remove the unused (and divergent) debugging macro definitions from the sun3_NCR5380 and atari_NCR5380 drivers. These drivers have been converted to use the common macros in NCR5380.h. Signed-off-by: Finn Thain fth...@telegraphics.com.au

Re: [PATCH v2 00/12] scsi/NCR5380: fix debugging macros and #include structure

Finn, On Tue, Apr 29, 2014 at 2:22 PM, Finn Thain fth...@telegraphics.com.au wrote: On Sat, 26 Apr 2014, James Bottomley wrote: OK, so this is a pretty big change to an unmaintained driver. I'll take it if you're willing to maintain the driver afterwards ... in which case I need another

Re: [PATCH v2 00/12] scsi/NCR5380: fix debugging macros and #include structure

Hi James, Perhaps Michael and Sam would be interested in sharing the role, for atari and sun3 NCR5380 drivers (?) If you insist ... (kidding - Im OK with it if James thinks it's worth it) As long as you understand how it works and how to fix it, the more the merrier. It gives me more people

Re: [PATCH] MAINTAINERS: add an entry for all the NCR5380 drivers

Acked-by: Michael Schmitz schmitz...@gmail.com On Mon, May 5, 2014 at 5:35 PM, Finn Thain fth...@telegraphics.com.au wrote: Signed-off-by: Finn Thain fth...@telegraphics.com.au Cc: Michael Schmitz schmitz...@gmail.com --- As requested: http://marc.info/?l=linux-arm-kernelm

Re: esp_scsi QTAG in FAS216

Hi Geert, [sorry for the long delay] Tell me about it :-) I haven't had a good idea how to address this problem so rather kept mum about it. On Mon, Apr 14, 2014 at 10:51 AM, Michael Schmitz schmitz...@gmail.com wrote: Not sure my patch had ever made it into Geert's m68k-queue - except

[PATCH] scsi_lib.c: avoid max_hw_segments warning

Hi, as per request by Geert Uytterhoeven: the patch below avoids a warning in blk_queue_max_hw_segments(), caused by a SCSI host adapter using SG_NONE. Please apply. The second item concerns a warning given for each SCSI target scanned on the Falcon, where sg_tablesize is set to SG_NONE (aka

Re: [PATCH] scsi_lib.c: avoid max_hw_segments warning

as per request by Geert Uytterhoeven: the patch below avoids a warning in blk_queue_max_hw_segments(), caused by a SCSI host adapter using SG_NONE. Please apply. Actually, isn't the correct fix to change SG_NONE to 1? We're deprecating the non-sg paths, however use_sg == 1 is equivalent

Re: DISABLE_CLUSTERING in scsi drivers

Christoph, for Atari SCSI, commands can only be merged if the physical addresses of all buffers are contiguous (limitation of the Falcon DMA engine). Documentation/scsi/scsi_mid_low_api.tx does not spell out whether that is the case. Atari SCSI disables scatter/gather, so if that's sufficient to

Re: DISABLE_CLUSTERING in scsi drivers

Am 26.11.2018 um 20:50 schrieb Christoph Hellwig: On Thu, Nov 22, 2018 at 10:11:33AM +1300, Michael Schmitz wrote: Christoph, for Atari SCSI, commands can only be merged if the physical addresses of all buffers are contiguous (limitation of the Falcon DMA engine). Documentation/scsi

Re: [PATCH v2] scsi: NCR5380: use msecs_to_jiffies for conversions

Finn, Nicholas, On Sat, 31 Jan 2015, Nicholas Mc Guire wrote: This is only an API consolidation to make things more readable. Instances of var * HZ / 1000 are replaced by msecs_to_jiffies(var). ... and some instances of value are replaced by msecs_to_jiffies(value) which seems to be

Re: [PATCH v2] scsi: NCR5380: use msecs_to_jiffies for conversions

Hi Nicholas, The values for USLEEP_* are taken to be in units jiffies, according to comments in NCR5380.c. Replacing them by the msecs_to_jiffies conversion is in fact wrong. Please drop the changes to g_NCR5380.c for that reason. right the comment indicates it should be jiffies - my

Re: [PATCH v3 00/77] More fixes, cleanup and modernization for NCR5380 drivers

Hi Finn, I've tested this series thoroughly on my Atari Falcon - no regressions, runs stable and is quite responsive. No SCSI lock-ups that had plagued the old driver (before your rewrites). Please add my Tested-by: Michael Schmitz <schmitz...@gmail.com> Cheers, Michael Am 22.12

Re: [PATCH v3 66/77] ncr5380: Fix soft lockups

I'd like to think that, too - probably true for the Atari TT SCSI case (can do scatter-gather, can do more than one command per LUN). Worse for the Falcon SCSI which is the only one I can test (no scatter-gather, one command per LUN, interrupt shared with IDE and IDE driver locked out while SCSI

Re: [PATCH 00/71] More fixes, cleanup and modernization for NCR5380 drivers

Hi Finn, >>> >>> I have compile-tested all patches to all NCR5380 drivers (x86, ARM, >>> m68k) and regression tested mac_scsi and dmx3191d modules on suitable >>> hardware. Testing the mac_scsi and dmx3191d modules provides only >>> limited coverage. It would be good to see some testing of ISA

Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT

Hi Finn, Am 18.11.2015 um 21:35 schrieb Finn Thain: > The bus reset may raise an interrupt. That would be new behaviour for > atari_scsi only when CONFIG_ATARI_SCSI_RESET_BOOT=n. The ST DMA interrupt > is not assigned to atari_scsi at this stage, so > CONFIG_ATARI_SCSI_RESET_BOOT=y may well be

Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT

Hi Finn, Am 19.11.2015 um 17:05 schrieb Finn Thain: > w > On Thu, 19 Nov 2015, Michael Schmitz wrote: > >> Hi Finn, >> >> Am 18.11.2015 um 21:35 schrieb Finn Thain: >> >>> The bus reset may raise an interrupt. That would be new behaviour for >>>

Re: [PATCH v4 34/78] atari_NCR5380: Use arbitration timeout

Hi Geert, On Mon, Jan 25, 2016 at 9:05 PM, Geert Uytterhoeven wrote: >>> Perhaps this is an ARAnyM quirk? > >> The MR_ARBITRATE bit should remain set until the driver clears it (or the >> reset logic clears it). But it looks like aranym simply discards writes to >> the

Re: [PATCH 00/22] ncr5380: Eliminate macros, reduce code duplication, fix bugs etc

Finn, tested successfully on Atari Falcon, so: Tested-by: Michael Schmitz <schmitz...@gmail.com> Am 14.03.2016 um 17:27 schrieb Finn Thain: > This patch series has more macro elimination and some tweaks to the > DMA hooks so that all the wrapper drivers can share the same core >

Re: [PATCH 0/6] ncr5380: Miscellaneous minor patches

Martin, Finn, I'll get to that on the weekend - Auckland Anniversary Day coming up so plenty of time. Cheers, Michael Am 26.01.2017 um 12:25 schrieb Martin K. Petersen: >> "Finn" == Finn Thain writes: > > Finn> Michael, Ondrej, can I get you to

Re: status of NCR5380-based ISA drivers

Christoph, I test the atari_scsi front end - haven't got any ISA cards handy. Probably no ISA slots on my PC main board either ... Cheers, Michael Am 12.09.2016 um 05:12 schrieb Christoph Hellwig: > Hi all, > > you seem to the currently active NCR580 cabal. Which frontends to NCR5380

Re: [PATCH v2 00/12] Fixes, cleanup and g_NCR5380_mmio/g_NCR5380 merger

ncr5380: Expedite register polling > scsi/ncr5380: Use correct types for DMA routines > scsi/ncr5380: Suppress unhelpful "interrupt without IRQ bit" message Tested on Atari SCSI (Falcon) - no regressions. Tested-by: Michael Schmitz <schmitz...@gmail.com> -- To u

Re: esp_scsi QTAG in FAS216

Hi Finn, Am 01.11.2016 um 12:47 schrieb Finn Thain: > > On Tue, 1 Nov 2016, Michael Schmitz wrote: > >>> I had tried to set that bit in zorro_esp_slave_configure but had not >>> done a proper job of it - I'd only set esp->config3 and forgot to set >&

Re: esp_scsi QTAG in FAS216

Hi Finn, Am 30.10.2016 um 15:33 schrieb Finn Thain: > > On Sat, 29 Oct 2016, I wrote: > >> >> On Sun, 13 Apr 2014, David Miller wrote: >> >>> >>> But oddly in the NCR53CX docs: >>> >>> >>> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR53C9X.txt >>> >>> it speaks as if

Re: esp_scsi QTAG in FAS216

Hi Finn, > I had tried to set that bit in zorro_esp_slave_configure but had not > done a proper job of it - I'd only set esp->config3 and forgot to set > tp->esp_config3. Time to retest this ... I don't think it's quite that easy - the ESP_CONFIG3_TENB bit needs to be set for all targets if at

Re: [PATCH] scsi/mac_esp: Replace bogus memory barrier with spinlock

Hi Martin, I must have missed that one - where was it posted to? Cheers, Michael Am 25.04.2017 um 10:29 schrieb Martin K. Petersen: > > Finn, > >> Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp chips") >> added mac_scsi_esp_intr() to handle the IRQ lines from a

Re: [PATCH] scsi/mac_esp: Replace bogus memory barrier with spinlock

Martin, looks good to me, so: Reviewed-By: Michael Schmitz <schmitz...@gmail.com> Am 25.04.2017 um 10:29 schrieb Martin K. Petersen: > > Finn, > >> Commit da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp chips") >> added mac_scsi_esp_intr(

Re: [PATCH v3 0/4] g_NCR5380: PDMA fixes and cleanup

Ondrej, could this be a partial write (target did not transfer the last byte)? One would suppose the chip posts a phase mismatch in that case ... Cheers, Michael Am 27.06.2017 um 18:28 schrieb Ondrej Zary: > On Monday 26 June 2017, Ondrej Zary wrote: >> On Monday 26 June 2017

[PATCH] m68k/atari: atari_scsi.c - use m68k_realnum_memory for FastRAM test

that. Tested by Christian Steiges on his Falcon with kernel loaded in FastRAM - could you please reply with your Tested-by tag, Christian? Signed-off-by: Michael Schmitz <schmitz...@gmail.com> --- drivers/scsi/atari_scsi.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/d

Re: [PATCH] m68k/atari: atari_scsi.c - use m68k_realnum_memory for FastRAM test

Hi Christian Am 06.06.2017 um 07:17 schrieb Christian T. Steigies: > On Mon, Jun 05, 2017 at 07:37:59PM +1200, Michael Schmitz wrote: >> m68k_num_memory is unsuitable to test for the presence of FastRAM >> on CT60 if the kernel is located in FastRAM: in arch/m68k/mm/motorola.c >

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

/53CF94_96-2_Fast_SCSI_Controller_Data_Manual_Apr1993.pdf Cheers, Michael On Tue, Mar 6, 2018 at 9:37 PM, Finn Thain <fth...@telegraphics.com.au> wrote: > On Tue, 6 Mar 2018, Michael Schmitz wrote: > >> The whole !write branch will never be executed, and I could just omit it &

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

Hi Geert, On Tue, Mar 6, 2018 at 8:48 PM, Geert Uytterhoeven wrote: > BTW, please call the probe/remove functions zorro_esp_probe() resp. > zorro_esp_remove(). Fair enough. + if (!host) { + pr_err(PFX "No host detected; board configuration

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

Hi Geert, fine, I'll rely on the base address and the z->rom.er_Type value to pick the correct config data. Cheers, Michael On Wed, Mar 7, 2018 at 9:06 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Michael, > > On Wed, Mar 7, 2018 at 8:55 AM, Michae

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

Hi Finn, Am 07.03.2018 um 13:54 schrieb Finn Thain: > On Wed, 7 Mar 2018, Michael Schmitz wrote: > >> The major obstacle now seems to be dynamic allocation of the driver >> private data and storing a pointer to that in a way that it can be >> retrieved us

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

Tuomas, Am 06.03.2018 um 04:31 schrieb Tuomas Vainikka: >>> I think you are talking about esp->regs? For esp->dma_regs, the >>> ioremap is >>> conditional on ent->id, but the unmap is not. >> The details of the ioremap are conditional on the ID, but the fact >> that the ioremap happens (and

[PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

Hi Geert, thanks for the review - largely uncontroversial except for the volatile... Am 14.03.2018 um 20:49 schrieb Geert Uytterhoeven: >> +/* Blizzard 1230 DMA interface */ >> + >> +struct blz1230_dma_registers { >> + volatile unsigned char dma_addr;/* DMA address [0x]

Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

Hi Finn, Am 12.03.2018 um 22:04 schrieb Finn Thain: >> +if (addr == esp->command_block_dma) >> +addr = (u32) esp->command_block; > > Since you've removed the alternative branch and phys_to_virt(), I suggest > you do this at function invocation... (see below) Keeps it together

Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

; -Tuomas > > From: linux-m68k-ow...@vger.kernel.org <linux-m68k-ow...@vger.kernel.org> on > behalf of Michael Schmitz <schmitz...@gmail.com> > Sent: 12 March 2018 09:26:40 > To: linux-scsi@vger.kernel.org > Cc: linux-m...@vger.kerne

Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

Hi Geert, Am 14.03.2018 um 21:30 schrieb Geert Uytterhoeven: > Hi Michael, > > On Wed, Mar 14, 2018 at 9:23 AM, Michael Schmitz <schmitz...@gmail.com> wrote: >> thanks for the review - largely uncontroversial except for the volatile... > > The presence of vo

Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

018, Michael Schmitz wrote: > >>> Please pass "addr" and "fifo" as macro parameters, too, so it's easier >>> for the reviewer to notice they are used. >> Yes, I can do that (meaning Finn would need to make the same change to >> keep our ve

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

Hi Finn, Geert, > + /* We are passed DMA addresses i.e. physical addresses, but must > use > +* kernel virtual addresses here, so remap to virtual. This is > easy > +* enough for the case of residual bytes of an extended message in > +*

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

to distinguish between Zorro II and Zorro III boards? Cheers, Michael Am 06.03.2018 um 20:43 schrieb Geert Uytterhoeven: > Hi Michael, > > On Tue, Mar 6, 2018 at 2:11 AM, Michael Schmitz <schmitz...@gmail.com> wrote: >> Index 1 should have been ZORRO_PROD_PHASE5_C

[PATCH v6] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

ute kernel virtual address esp->cmd_block in PIO transfer call if DMA address is esp->cmd_block_dma and phase is message in. PIO code taken from mac_esp.c where the reselection timeout issue was debugged and fixed first, with minor macro and function rename. Signed-off-by: Michael Schmitz

Re: [PATCH v6] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Finn, Am 07.04.2018 um 12:59 schrieb Finn Thain: > On Sat, 7 Apr 2018, Michael Schmitz wrote: > >> Changes since v5: >> >> Christoph Hellwig: >> >> - fix comment style >> - drop initialization to zero in driver data init >> - fix alignment in

Re: [PATCH v6] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Finn, Am 07.04.2018 um 22:19 schrieb Finn Thain: > On Sat, 7 Apr 2018, Michael Schmitz wrote: > >>> >>> CHECK /home/fthain/src/kernel.org/linux/drivers/scsi/zorro_esp.c >>> drivers/scsi/zorro_esp.c:274:14: warning: cast removes address space of >>&g

Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

On Tue, Apr 10, 2018 at 8:18 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Michael, > > On Tue, Apr 10, 2018 at 4:16 AM, Michael Schmitz <schmitz...@gmail.com> wrote: >> On Mon, Apr 9, 2018 at 7:50 PM, Christoph Hellwig <h...@infradead.org> wrote: >>>

Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Geert, Am 11.04.2018 um 18:51 schrieb Geert Uytterhoeven: > Hi Michael, > > On Tue, Apr 10, 2018 at 11:50 PM, Michael Schmitz <schmitz...@gmail.com> > wrote: >>>> Short of a complete rewrite of the Zorro driver support code to be >>>> closer to

[PATCH v8] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Geert, Christoph, Am 11.04.2018 um 20:30 schrieb Geert Uytterhoeven: > Hi Christoph, > > On Wed, Apr 11, 2018 at 10:11 AM, Christoph Hellwig > wrote: >> On Wed, Apr 11, 2018 at 10:03:12AM +0200, Geert Uytterhoeven wrote: That would be cool. Would that still be in

Re: [PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

, 2018 at 7:50 PM, Christoph Hellwig <h...@infradead.org> wrote: > On Sun, Apr 08, 2018 at 02:45:32PM +1200, Michael Schmitz wrote: >> New combined SCSI driver for all ESP based Zorro SCSI boards for >> m68k Amiga. >> >> Code largely based on board specific pa

[PATCH v7] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

ute kernel virtual address esp->cmd_block in PIO transfer call if DMA address is esp->cmd_block_dma and phase is message in. PIO code taken from mac_esp.c where the reselection timeout issue was debugged and fixed first, with minor macro and function rename. Signed-off-by: Michael Schmitz

Re: [PATCH v8] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Geert, On Wed, Apr 11, 2018 at 8:56 PM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > Hi Michael, > > On Wed, Apr 11, 2018 at 10:36 AM, Michael Schmitz <schmitz...@gmail.com> > wrote: >> From: Michael Schmitz <schm...@debian.org> >> >>

[PATCH v9] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

Re: [PATCH v9] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Martin, thank you so much! Ben - please drop the Amiga SCSI patch for Debian testing from kernel version 4.18! Cheers, Michael Am 19.04.2018 um 16:01 schrieb Martin K. Petersen: > > Michael, > >> Anything else needed for linux-scsi? > > Applied to 4.18/scsi-queue. Thanks! >

Re: [PATCH v9] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Thanks guys! Anything else needed for linux-scsi? Cheers, Michael On Mon, Apr 16, 2018 at 10:34 PM, John Paul Adrian Glaubitz <glaub...@physik.fu-berlin.de> wrote: > On 04/16/2018 11:26 AM, Christian T. Steigies wrote: >> >> On Thu, Apr 12, 2018 at 01:53:26PM +1200,

[PATCH v5] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

Re: [PATCH v5] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

Hi Christoph, thank you for taking the time to review and comment - my responses inline below. Am 03.04.2018 um 19:45 schrieb Christoph Hellwig: > Just a few style comments: > >> +static int zorro_esp_irq_pending(struct esp *); >> +static int cyber_esp_irq_pending(struct esp *); >> +static int

[PATCH v4] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

Re: [PATCH v4] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c

Hi Kars, thanks, I've fixed that typo. Cheers, Michael Am 19.03.2018 um 03:51 schrieb Kars de Jong: > Hi Michael, > > 2018-03-17 2:16 GMT+01:00 Michael Schmitz <schmitz...@gmail.com>: >> From: Michael Schmitz <schm...@debian.org> >> >> New combi

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 <schm...@debian.org> >> >> New combined SCSI driver for all ESP based Zorro SCSI boards for >> m68k Amiga. &g

[PATCH 0/2] Revive Amiga Zorro ESP SCSI driver

At long last, revive the driver for m68k Amiga Zorro boards based on the Qlogic ESP SCSI chip, which were in-tree as separate drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c) until the rewrite of the ESP core code after 2.6.x. A previous rewrite of the Zorro ESP SCSI

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

From: Michael Schmitz <schm...@debian.org> New combined SCSI driver for all ESP based Zorro SCSI boards for m68k Amiga. Code largely based on board specific parts of the old drivers (blz1230.c, blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed after the 2.6 kernel

[PATCH 1/2] m68k/amiga - Zorro ESP SCSI Makefile/Kconfig support

From: Michael Schmitz <schm...@debian.org> Add Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI driver (combining old blz1230, blz2060, cyberstorm and fastlane SCSI drivers that were removed for lack of maintenance after 2.6) Signed-off-by: Michael Schmitz <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 SCS

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

Hi Finn, On Mon, Mar 5, 2018 at 2:01 PM, Finn Thain <fth...@telegraphics.com.au> wrote: > On Mon, 5 Mar 2018, Michael Schmitz wrote: > >> >> +fail_unmap_dma_regs: >> >> + if (ioaddr > 0xff) >> >> + iounmap

  1   2   >