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 > wrote: Short of a complete rewrite of the Zorro driver support code to be closer to what PCI does, I don' see what can be done

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

On 04/11/2018 08:51 AM, Geert Uytterhoeven wrote: I don't have a preference. If you think it makes the driver easier to read, go for it. That would be cool. Would that still be in time for the 4.17 merge? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer -

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

On Wed, Apr 11, 2018 at 10:03:12AM +0200, Geert Uytterhoeven wrote: > > That would be cool. Would that still be in time for the 4.17 merge? > > Nope, as new drivers need to be in linux-next before the merge window opens. I always throught that entirely new drivers were an exception to that. --

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] bug.h: Work around GCC PR82365 in BUG()

On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote: > On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote: > > Before I forward port those patches to add .insn for MIPS, is that sort > > of approach (an arch specific asm/compiler-gcc.h to allow MIPS to > > override

Re: [PATCH] bug.h: Work around GCC PR82365 in BUG()

On Wed, Apr 11, 2018 at 12:08:51PM +0200, Arnd Bergmann wrote: > On Wed, Apr 11, 2018 at 11:54 AM, James Hogan wrote: > > On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote: > >> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote: > >> > Before I

Re: [PATCH] bug.h: Work around GCC PR82365 in BUG()

On Wed, Apr 11, 2018 at 11:54 AM, James Hogan wrote: > On Wed, Apr 11, 2018 at 09:30:56AM +0200, Arnd Bergmann wrote: >> On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote: >> > Before I forward port those patches to add .insn for MIPS, is that sort >> > of

[PATCH 05/15] m68k: group io mapping definitions and functions

Create a new header file, kmap.h, that groups all the definitions and functions associated with the io mapping and remapping. Currently the functions are spread across raw_io.h and io_mm.h. And in the future we will want to use these in io_no.h as well. So it makes sense to move them all together

[PATCH 04/15] m68k: rework raw access macros for the non-MMU case

The primary and fundamental access macros are really the __raw versions. So make them the actual implementation for access, and not the read/write access macros. The read/write macros and functions are built on top of the raw access (with byte swapping or other actions as required). This in

[PATCH 07/15] m68k: use io_no.h for MMU and non-MMU enabled ColdFire

Use the io_no.h IO access support for all ColdFire systems, no matter whether configured with MMU enabled or disabled. Previously there was subtle differences in IO access functions used in both cases, and these resulted in broken behavior for some drivers. As observed and reported by Angelo when

[PATCH 09/15] m68k: don't redefine access functions if we have PCI

Some ColdFire platforms do have real PCI buses, so we should not be re-defining or otherwise mangling the IO access functions for them. So when CONFIG_PCI is true use the real io.h support. Signed-off-by: Greg Ungerer --- arch/m68k/include/asm/vga.h | 8 1 file

[PATCH 03/15] m68k: use asm-generic/io.h for non-MMU io access functions

There is nothing really special about the non-MMU m68k IO access functions. So we can easily switch to using the asm-generic/io.h functions. The only thing we do need to handle is that historically the m68k IO access functions for readw/readl/writew/writel use native CPU endian ordering. So for

[PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

Move a copy of the definitions of the *_relaxed() macros into io_no.h and io_mm.h. This precedes a change to the io_no.h file to use asm-generic/io.h. They will be removed from io_no.h at that point. Signed-off-by: Greg Ungerer --- arch/m68k/include/asm/io.h| 8

[PATCH 02/15] m68k: put definition guards around virt_to_phys and phys_to_virt

The non-MMU and ColdFire IO access functions will be moving to using the asm-generic/io.h in the near future. To make that possible we need define guards around the m68k specific virt_to_phys() and phys_to_virt() functions. Signed-off-by: Greg Ungerer ---

[PATCH 00/15] m68k: fix and improve IO access

Convert the ColdFire IO access functions to use asm-generic/io.h. The motivation for these changes is to fix IO access problems found by Angelo Dureghello during his work on ColdFire 5441x when running with MMU enabled. It also bought to light problems with ColdFire systems that have PCI bus

[PATCH 06/15] m68k: setup PCI support code in io_no.h

Ultimately we want the ColdFire IO access support to be consisent no matter whether it is configured with MMU enabled or disabled. To acheive that we need to get all the ColdFire IO access support code together in one place, in this case io_no.h. The last big piece not in io_no.h is the PCI bus

[PATCH 13/15] m68k: force use of __raw_read/__raw_write address to be iomem

The __raw_read/__raw_write and read/write families of IO access functions normally take address arguments of type "void __iomem *". The legacy macros we are still using for ColdFire and non-MMU m68k don't really care, they cast to volatile unsigned pointers of appropriate size to do their work.

[PATCH 14/15] m68k: remove local __raw_read/__raw_write macros for non-MMU

Now that all the local ColdFire and non-MMU m68k use of __raw_read and __raw_write has been made type clean we can switch to using the asm-generic/io.h versions. Signed-off-by: Greg Ungerer --- arch/m68k/include/asm/io_no.h | 32 ++-- 1 file

[PATCH 15/15] m68k: fix ColdFire PCI config reads and write

The ColdFire PCI configuration space access functions swap addressing regions to do their work. Just letting the read/write cycles exit the CPU core (via the ColdFire "nop" instruction) is not enough to guarantee that the address region remapping has actually completed. Insert a read back of the

[PATCH 10/15] m68k: fix read/write multi-byte IO for PCI on ColdFire

We need to treat built-in peripherals and bus based address ranges differently. Local built-in peripherals (and the ColdFire SoC parts have quite a lot of them) are always native endian - which is big endian on m68k/ColdFire. Bus based address ranges, like the PIC bus, are accessed little endian -

[PATCH 08/15] m68k: remove old ColdFire IO access support code

All the ColdFire IO access support code has been moved to io_no.h. This means that all ColdFire support is at least now consistent no matter whether the MMU is enabled or not for them. Now that io_mm.h has reverted to only support the traditional m68k MMU enabled processors we can remove the

[PATCH 11/15] m68k: fix ioremapping for internal ColdFire peripherals

The ColdFire SoC internal peripherals are mapped into virtual address space using the ACR registers of the cache control unit. This means we are using a 1:1 physical:virtual mapping for them that does not rely on page table mappings. We can quickly determine if we are accessing an internal

[PATCH 12/15] m68k: allow ColdFire PCI bus on MMU and non-MMU configuration

Up to now we have only had support for the PCI bus when running the ColdFire CPU family with the MMU enabled. The only reason for this was the incomplete state of the IO remapping and access functions when running with the MMU disabled. Recent fixes and improvements to the ColdFire IO access code

Re: [PATCH 01/15] m68k: move *_relaxed macros into io_no.h and io_mm.h

On Wed, Apr 11, 2018 at 2:54 PM, Greg Ungerer wrote: > Move a copy of the definitions of the *_relaxed() macros into io_no.h > and io_mm.h. This precedes a change to the io_no.h file to use > asm-generic/io.h. They will be removed from io_no.h at that point. > >

[PATCH v2 02/10] m68k/mac: Fix SWIM memory resource end address

The resource size is 0x2000 == end - start + 1. Therefore end == start + 0x2000 - 1. Cc: Laurent Vivier Cc: sta...@vger.kernel.org # v4.14+ Tested-by: Stan Johnson Signed-off-by: Finn Thain Acked-by: Laurent Vivier

[PATCH v2 06/10] block/swim: Don't log an error message for an invalid ioctl

The 'eject' shell command may send various different ioctl commands. This leads to error messages on the console even though the FDEJECT ioctl succeeds. ~# eject floppy SWIM floppy_ioctl: unknown cmd 21257 SWIM floppy_ioctl: unknown cmd 1 Don't log an error message for an invalid ioctl, just do

[PATCH v2 05/10] block/swim: Remove extra put_disk() call from error path

Cc: Laurent Vivier Cc: Jens Axboe Cc: sta...@vger.kernel.org # v4.14+ Fixes: 103db8b2dfa5 ("[PATCH] swim: stop sharing request queue across multiple gendisks") Tested-by: Stan Johnson Signed-off-by: Finn Thain

[PATCH v2 08/10] block/swim: Check drive type

The SWIM chip is compatible with GCR-mode Sony 400K/800K drives but this driver only supports MFM mode. Therefore only Sony FDHD drives are supported. Skip incompatible drives. Cc: Laurent Vivier Cc: Jens Axboe Cc: sta...@vger.kernel.org # v4.14+ Tested-by:

[PATCH v2 03/10] m68k/mac: Don't remap SWIM MMIO region

For reasons I don't understand, calling ioremap() then iounmap() on the SWIM MMIO region causes a hang on 68030 (but not on 68040). ~# modprobe swim_mod SWIM floppy driver Version 0.2 (2008-10-30) SWIM device not found ! watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [modprobe:285] Modules

[PATCH] block/amiflop: Don't log an error message for an invalid ioctl

Do as the swim3 driver does and just return -ENOTTY. Cc: Geert Uytterhoeven Cc: linux-m...@lists.linux-m68k.org Signed-off-by: Finn Thain --- drivers/block/amiflop.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

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 wrote: > Hi Michael, > > On Wed, Apr 11, 2018 at 10:36 AM, Michael Schmitz > wrote: >> From: Michael Schmitz >> >> New combined SCSI driver for all ESP based Zorro

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

From: Michael Schmitz 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 series for

[PATCH v2 04/10] block/swim: Fix array bounds check

In the floppy_find() function in swim.c is a call to get_disk(swd->unit[drive].disk). The actual parameter to this call can be a NULL pointer when drive == swd->floppy_count. This causes an oops in get_disk(). Data read fault at 0x0198 in Super Data (pc=0x1be5b6) BAD KERNEL BUSERR Oops:

[PATCH v2 09/10] block/swim: Fix IO error at end of medium

Reading to the end of a 720K disk results in an IO error instead of EOF because the block layer thinks the disk has 2880 sectors. (Partly this is a result of inverted logic of the ONEMEG_MEDIA bit that's now fixed.) Initialize the density and head count in swim_add_floppy() to agree with the

[PATCH v2 00/10] SWIM driver fixes

This patch series has fixes for bugs in the SWIM floppy disk controller driver, including an oops and a soft lockup. One way to apply these patches to v4.14+ is by first cherry-picking these commits: b87eaec27eca3def6c8ed617e3b1bac08d7bc715 e5f0d2e2a153b18dcf31e1a633e210c37829d759 There are of

[PATCH v2 10/10] block/swim: Select appropriate drive on device open

The driver supports internal and external FDD units so the floppy_open function must not hard-code the drive location. Cc: Laurent Vivier Cc: Jens Axboe Cc: sta...@vger.kernel.org # v4.14+ Tested-by: Stan Johnson Signed-off-by: Finn Thain

[PATCH v2 07/10] block/swim: Rename macros to avoid inconsistent inverted logic

The Sony drive status bits use active-low logic. The swim_readbit() function converts that to 'C' logic for readability. Hence, the sense of the names of the status bit macros should not be inverted. Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and TWOMEG_MEDIA macros have