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 lack of maintenance)
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 SCSI boards for
>> m68k Amiga.
>
> Thanks a lot!
My pleasure entire
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 a/drivers/block/amiflop.c b/drivers/block/amiflop.c
index 3a
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
Acked-by: Laurent Vivier
Reviewed-by: Geert Uytterhoeven
---
drivers/block/swim.c
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: Stan Johnson
Signed-off-by: Finn Thai
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 link
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 a
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: 00
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 devic
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
Acked-by: Laurent Vivier
---
drivers/block/swim.c | 2
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 inverted
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 cou
Rename floppy_type macros to make them more consistent with the scsi_type
macros, which are named after classes of models with similar memory maps.
The documentation for LC-class machines has the IO devices at offsets
from $50F0 . Use these addresses (consistent with mac_scsi resources)
becaus
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
Reviewed-by: Geert Uytterhoeven
---
arch/m68k/mac/config.c | 2 +-
1 file cha
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.
>
> Signed-off-by: Greg Ungerer
Revie
On Wed, Apr 11, 2018 at 2:54 PM, Greg Ungerer wrote:
> 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-of
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 changed, 18 insertions(+),
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 ma
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.
Th
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
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 peripher
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 -
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 ColdF
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 changed, 8 insertions(+)
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
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 itself
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
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
sup
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
---
arch/m68k/include/asm/virtconvert.h | 2
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 suppo
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 us
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
arch/m68k/include/as
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 forward port those patches to add .ins
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 approach (an arch specific asm/compile
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 barrier_before_unreac
On 04/11/2018 10:55 AM, Michael Schmitz wrote:
Would be nice but this has been chugging along for over four years in my
queue so I'm sure it can wait a few more weeks :-)
But the driver works very well now, so it was worth the wait ;-).
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Devel
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 SCSI boards for
> m68k Amiga.
Thanks a lot!
> --- /dev/null
> +++ b/drivers/scsi/zorro_esp.c
> +static const struct zorro_device_id zorro_esp_zorro
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 time for the 4.17 merge
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 about the use of
Zorro
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 lack of maintenance)
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 time for the 4.17 merge?
>>
>> Nope, as new drivers need to be in linux-next before the merge window opens
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.
--
To
Hi Adrian,
On Wed, Apr 11, 2018 at 9:59 AM, John Paul Adrian Glaubitz
wrote:
> 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?
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 - glaub...@debian.o
On Wed, Apr 11, 2018 at 12:48 AM, James Hogan wrote:
> Hi Arnd,
>
> On Tue, Dec 19, 2017 at 12:39:33PM +0100, Arnd Bergmann wrote:
>> diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h
>> index 5d595cfdb2c4..66cfdad68f7e 100644
>> --- a/include/linux/compiler-gcc.h
>> +++ b/i
45 matches
Mail list logo
