On 19/02/21 12:19 am, Arnd Bergmann wrote:
drivers/net/ethernet/8390/apne.c
drivers/net/ethernet/8390/ax88796.c
drivers/net/ethernet/8390/hydra.c
drivers/net/ethernet/8390/mac8390.c
drivers/net/ethernet/8390/ne.c
drivers/net/ethernet/8390/zorro8390.c
[...]
Most of these are normal short-lived
Hi Finn,
works fine, thanks!
Tested-By: Michael Schmitz
On 1/12/20 7:46 PM, Finn Thain wrote:
The in_interrupt() macro is deprecated. Also, it's usage in
NCR5380_poll_politely2() has long been redundant.
Cc: Sebastian Andrzej Siewior
Cc: Ahmed S. Darwish
Cc: Thomas Gleixner
Link:
Hi Finn,
thanks for your patch!
Tested on Atari Falcon (with falconide, and pata_falcon modules).
Reviewed-by: Michael Schmitz
Tested-by: Michael Schmitz
Am 20.11.2020 um 17:39 schrieb Finn Thain:
It is possible that bus_reset_cleanup() or .eh_abort_handler could
be invoked during
Hi Finn,
thanks for your patch!
Tested on Atari Falcon (with falconide, and pata_falcon modules).
Reviewed-by: Michael Schmitz
Tested-by: Michael Schmitz
Am 20.11.2020 um 17:39 schrieb Finn Thain:
Refactor to avoid needless calls to NCR5380_maybe_release_dma_irq().
This makes the machine
Hi Mike,
On 29/10/20 12:16 AM, Mike Rapoport wrote:
Hi Geert,
On Wed, Oct 28, 2020 at 10:25:49AM +0100, Geert Uytterhoeven wrote:
Hi Mike,
On Tue, Oct 27, 2020 at 12:31 PM Mike Rapoport wrote:
From: Mike Rapoport
The pg_data_t node structures and their initialization currently depends on
Hi Finn,
thanks for catching this!
Reviewed-By: Michael Schmitz
Am 25.09.2020 um 13:39 schrieb Finn Thain:
Unloading the falconide module results in a crash:
Unable to handle kernel NULL pointer dereference at virtual address
Oops:
Modules linked in: falconide(-)
PC
Hi Finn,
On 24/09/20 1:07 PM, Finn Thain wrote:
Looking further at the drivers using ide_host_register(), I see that
falconide.c is missing a set_drvdata() call, while tx4939ide.c calls
set_drvdata() after ide_host_register(). The latter example is not a bug.
The pattern I used, that is, callin
Hi Finn,
Am 10.09.2020 um 12:23 schrieb Finn Thain:
+ return 0;
+
+release_mem:
+ release_mem_region(mem->start, resource_size(mem));
Not needed, as you used devm_*() for allocation.
OK, I'll remove this. I put it there after I looked at falconide.c and
wondered whether the auto
Martin,
On 19/06/19 12:47 PM, Martin K. Petersen wrote:
Michael,
No matter - patch applied cleanly to what I'm running on my Falcon,
and works just fine for now (stresstest will take a few hours to
complete). And that'll thoroughly exercise the reselection code path,
from what we've seen befor
On 11/06/19 3:25 PM, Finn Thain wrote:
My understanding is that support for chained scatterlists is to
become mandatory for LLDs.
Cc: Michael Schmitz
Signed-off-by: Finn Thain
Reviewed-by: Michael Schmitz
---
drivers/scsi/NCR5380.c | 41 ++---
1 file
Hi Finn,
On 11/06/19 9:33 PM, Finn Thain wrote:
On Tue, 11 Jun 2019, Michael Schmitz wrote:
Hi Finn,
IIRC I'd tested that change as well - didn't change broken target
behaviour but no regressions in other respects. Add my tested-by if
needed.
Unfortunately I can't confirm t
n() after
calls to NCR5380_select() and NCR5380_information_transfer() return.
Cc: Michael Schmitz
Cc: sta...@vger.kernel.org # v4.9+
Fixes: 8b00c3d5d40d ("ncr5380: Implement new eh_abort_handler")
Tested-by: Stan Johnson
Signed-off-by: Finn Thain
---
drivers/scsi/NCR5380.c | 12 ++-
Hi Finn,
Thanks - can't test this on my hardware but looks good to me.
Cheers,
Michael
Am 11.06.2019 um 15:25 schrieb Finn Thain:
My understanding is that support for chained scatterlists is to
become mandatory for LLDs.
Cc: Michael Schmitz
Signed-off-by: Finn Thain
---
dr
Hi Finn,
On 3/06/19 7:40 PM, Finn Thain wrote:
There are several other drivers that contain pieces of assembler code.
Does any driver contain assembler code for multiple architectures? I was
trying to avoid that -- though admittedly I don't yet have actual code for
the PDMA implementation fo
Hi,
Am 14.05.2019 um 13:22 schrieb Michael Schmitz:
Stephen,
I wasn't aware of the other asix module when submitting the phy driver.
The phy module gets autoloaded based on the PHY ID, so there's no reason
why it couldn't be renamed.
May I suggest ax88796b for the new module n
Stephen,
I wasn't aware of the other asix module when submitting the phy driver.
The phy module gets autoloaded based on the PHY ID, so there's no reason
why it couldn't be renamed.
May I suggest ax88796b for the new module name?
Cheers,
Michael
On 14/05/19 12:56 PM, Stephen Rothwell
abel and
retain reason for fall-through in comment as
requested by Michael Schmitz.
drivers/scsi/NCR5380.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/NCR5380.c b/drivers/scsi/NCR5380.c
index 01c23d27f290..985d1c053578 100644
--- a/drivers/scsi
orrect SPDX tag
was added in response to checkpath complaints. So 2.0+ would be correct.
Thomas: does that suit your purpose?
Cheers,
Michael
On 21/01/19 6:43 AM, Andrew Lunn wrote:
On Fri, Jan 18, 2019 at 11:22:39AM +0100, Thomas Gleixner wrote:
Michael,
On Thu, 19 Apr 2018, Michae
Christophe,
Am 30.12.2018 um 05:55 schrieb LEROY Christophe:
Michael Schmitz a écrit :
Hi Finn,
Am 29.12.2018 um 14:06 schrieb Finn Thain:
On Fri, 28 Dec 2018, LEROY Christophe wrote:
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d
Tested-by: Christian T. Steigies
Acked-by: Michael Schmitz
---
This patch temporarily disables CONFIG_NVRAM on Atari, to prevent build
failures when bisecting the rest of this patch series. It gets enabled
again with the introduction of CONFIG_HAVE_ARCH_NVRAM_OPS, once the
nvram_* global functions
Hi Finn,
Am 29.12.2018 um 15:34 schrieb Finn Thain:
On Sat, 29 Dec 2018, Michael Schmitz wrote:
IS_BUILTIN(CONFIG_NVRAM) is probably what Christophe really meant to suggest.
Or (really going out on a limb here):
IS_BUILTIN(CONFIG_NVRAM) ||
( IS_MODULE(CONFIG_ATARI_SCSI) && IS
Hi Finn,
Am 29.12.2018 um 14:06 schrieb Finn Thain:
On Fri, 28 Dec 2018, LEROY Christophe wrote:
diff --git a/drivers/scsi/atari_scsi.c b/drivers/scsi/atari_scsi.c
index 89f5154c40b6..99e5729d910d 100644
--- a/drivers/scsi/atari_scsi.c
+++ b/drivers/scsi/atari_scsi.c
@@ -755,9 +755,10 @@ static
Hi Finn,
Am 25.11.2018 um 14:15 schrieb Finn Thain:
Maybe the timer interrupt has a sufficiently high priority and latency is
low? Maybe cia_set_irq() is really expensive?
I don't know the platform well enough so I'm inclined to revert. We can
benchmark gettimeofday syscalls on elgar but is tha
Am 20.11.2018 um 23:02 schrieb Andreas Schwab:
On Nov 20 2018, Linus Walleij wrote:
Yes you already see the same as I see: this chip MK68901 has
no less than four timers. I bet the kernel is just using one of them,
out of habit.
Note that not all timers can be used freely. Some of them ar
onger uniformly distributed.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
Tested-by: Michael Schmitz
---
TODO: find a spare counter for the clocksource, rather than hanging
it off the HZ timer.
It would be simpler to adopt the 'jiffies' clocksource here
(c.f. patch for the hp300 p
Hi Finn,
Am 17.11.2018 um 11:49 schrieb Finn Thain:
On Fri, 16 Nov 2018, Russell King - ARM Linux wrote:
The EBSA110 is probably in a similar boat - I don't remember whether it
had 16MB or 32MB as the maximal amount of memory, but memory was getting
tight with some kernels even running a mini
Hi Finn
Am 15.11.2018 um 12:54 schrieb Michael Schmitz:
That one does appear to work - different versions of ARAnyM, and
different userland versions though. I'll test that again with the setup
that saw c606b5cf902 fail.
Still fails on that emulator / userland.
Must be a quirk of A
On 14/11/18 8:58 PM, Russell King - ARM Linux wrote:
Are you saying that's not possible on arm, because the current timer rundown
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event (coul
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appe
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work - different versions of ARAnyM, and
differen
On 14/11/18 12:43 PM, Russell King - ARM Linux wrote:
On Wed, Nov 14, 2018 at 08:55:37AM +1100, Finn Thain wrote:
On Tue, 13 Nov 2018, Russell King - ARM Linux wrote:
On Tue, Nov 13, 2018 at 02:39:00PM +1100, Finn Thain wrote:
You could remove the old arch_gettimeoffset API without dropping
Hi Finn,
On 14/11/18 11:11 AM, Finn Thain wrote:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Running a recent kernel under ARAnyM shows 40 ns resolution so the Atari
hardware emulation is a little more complete.
You mean, 40 us resolution, right?
Sorry, typo. Should have been us of course
Hi Finn,
Am 13.11.2018 um 19:15 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
(It appears that a QEMU-emulated Mac does not benefit from having a
clocksource that's more accurate than the 'jiffies' clocksource, in
spite of "clocksource: Switched
Hi Finn,
Am 13.11.2018 um 16:14 schrieb Finn Thain:
On Tue, 13 Nov 2018, Michael Schmitz wrote:
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain
wrote:
The
Hi Finn,
Am 12.11.2018 um 22:06 schrieb Finn Thain:
On Mon, 12 Nov 2018, Geert Uytterhoeven wrote:
Hi Finn,
Thanks for your patch!
On Mon, Nov 12, 2018 at 5:46 AM Finn Thain wrote:
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent patches.
Hi Adrian,
my fix is evidently incomplete - I just crashed elgar trying to remove
the pata_buddha module, sorry. Must've done something silly.
So no, can't post a patch to add module_exit just yet.
Cheers,
Michael
Am 31.10.2018 um 23:06 schrieb John Paul Adrian Glaubitz:
Hi!
On 1
Hi Bartlomiej,
On 19/10/18 01:29, Bartlomiej Zolnierkiewicz wrote:
Add Buddha PATA controller driver. It enables libata support for
the Buddha, Catweasel and X-Surf expansion boards on the Zorro
expansion bus.
Cc: John Paul Adrian Glaubitz
Cc: Michael Schmitz
Cc: Geert Uytterhoeven
Signed
Hi Adrian,
module built and loaded fine (no need to build a new kernel for this).
Can't unload the module however (-EBUSY).
You'll have to reboot elgar to reload the module, I'm afraid.
Cheers,
Michael
On 19/10/18 01:32, John Paul Adrian Glaubitz wrote:
Hi!
On 10/18/18 2:29 PM, Bart
Hi Geert,
On 10/10/18 19:59, Geert Uytterhoeven wrote:
Hi Michael,
On Wed, Oct 10, 2018 at 12:07 AM Michael Schmitz wrote:
I agree the bug is neither subtle nor recent, not security relevant and
will affect only a handful of users at best.
If you're worried about weakening the rules a
lease.
Cheers,
Michael
On 09/10/18 08:20, Dmitry Torokhov wrote:
Hi Michael,
On Mon, Oct 8, 2018 at 12:09 PM Michael Schmitz wrote:
Dmitry,
someone on debian-68k reported the bug, which (to me) indicates that the
code is not just used by me.
Whether or not a functioning Capslock is essenti
patches without explicit action on behalf of
the maintainer. Unstable patches are a little harder to get accepted.
Cheers,
Michael
On 09/10/18 06:11, Dmitry Torokhov wrote:
On Mon, Oct 8, 2018 at 8:25 AM Sasha Levin wrote:
From: Michael Schmitz
[ Upstream commit
Am 05.10.2018 um 15:16 schrieb Leonardo Bras:
Well it's not really that persuasive. Most people simply let the build
run to completion, but if you have a problem with a job control 3h
timelimit, then create a job that kills itself at 2:59 and then
resubmits itself. That will produce a comple
lost a delightful drawing. Jerry reported it. Amigoids screamed. I tried
to tell them I was there, it was my machine, and 1.1 was, indeed, crap.
{o.o}
On 20180627 02:00, Michael Schmitz wrote:
Joanne,
I'm not at all allergic to avoiding RDB at all cost for new disks. If
AmigaOS 4.1 support
to make a bonehead stupid move and lose all his treasured disk
archives. Doing otherwise is very poor form.
{o.o} Joanne "Said enough, she has" Dow
On 20180626 18:07, Michael Schmitz wrote:
Joanne,
As far as I have been able to test, the change is backwards compatible
(RDB partitions
robably smart enough to keep it working for
> yourself.
>
> GPT is probably the right way to go. Preserve the ability to read RDBs for
> legacy disks only.
>
> {^_^}
>
>
> On 20180626 01:31, Michael Schmitz wrote:
>>
>> Joanne,
>>
>> I think we all agree
Hi Martin,
Am 26.06.18 um 20:02 schrieb Martin Steigerwald:
> Michael.
>
> Michael Schmitz - 26.06.18, 04:23:
>> Joanne,
>>
>> Martin's boot log (including your patch) says:
>>
>> Jun 19 21:19:09 merkaba kernel: [ 7891.843284] sdb: RDSK (512) sdb1
&g
under
> 1% of the disk all by itself. A block bitmap is not quite so bad. {^_-}
>
> Just be sure you are aware of all the ramifications when you make a
> change. I remember thinking about this for awhile and then determining
> I REALLY did not want to think about it as my brain was getting tied
gt; 219902322 bytes. But that wastes just a WHOLE LOT of disk in block maps.
> Go up to 4096 or 8192. The latter is 35 TB.
>
> {^_^}
> On 20180624 02:06, Martin Steigerwald wrote:
>>
>> Hi.
>>
>> Michael Schmitz - 27.04.18, 04:11:
>>>
>>> test r
CSI
bridge to test this properly on).
Cheers,
Michael
Am 24.06.18 um 21:06 schrieb Martin Steigerwald:
> Hi.
>
> Michael Schmitz - 27.04.18, 04:11:
>> test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
>> indicate the RDB parser bug is fixed by the patch g
Hi Finn,
On Tue, May 29, 2018 at 5:38 PM, Finn Thain wrote:
> I found some patches here,
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent.2
That's the most recent IIRC. Haven't begun looking at that yet - still stuck at
git://git.infradead.org/users/hch/
Hi Finn,
Am 29.05.2018 um 14:15 schrieb Finn Thain:
>
> Since an arch gets to apply limits in the dma ops it implements, why would
> arch code also have to set a limit in the form of default platform device
> masks? Powerpc seems to be the only arch that does this.
One of Christoph's recent pa
y to happen any time.
Just my $0.02 ...
Cheers,
MIchael
On Mon, May 28, 2018 at 10:15 PM, Geert Uytterhoeven
wrote:
> On Mon, May 28, 2018 at 7:26 AM, Finn Thain
> wrote:
>> On Mon, 28 May 2018, Michael Schmitz wrote:
>>> Am 27.05.2018 um 17:49 schrieb Finn Thain:
>&g
Hi Finn,
Am 27.05.2018 um 17:49 schrieb Finn Thain:
> On Sun, 27 May 2018, Michael Schmitz wrote:
>
>> That should have fixed the warning already ...
>
> It's still not fixed (hence my "acked-by" for Geunter's patch).
>
Odd - doe
Hi Finn,
was your patch to implement this in arch_setup_pdev_archdata() rejected?
That should have fixed the warning already ...
Am 27.05.2018 um 15:01 schrieb Finn Thain:
> On Sat, 26 May 2018, Guenter Roeck wrote:
>
>> As of commit 205e1b7f51e4 ("dma-mapping: warn when there is no
>> coherent_
Hi Finn,
Am 11.05.2018 um 22:06 schrieb Finn Thain:
>> You would have to be careful not to overwrite a pdev->dev.dma_mask and
>> pdev->dev.dma_coherent_mask that might have been set in a platform
>> device passed via platform_device_register here. Coldfire is the only
>> m68k platform currently
Hi Finn,
Am 11.05.2018 um 17:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
>
>>
>> I'm afraid using platform_device_register() (which you already use for
>> the SCC devices) is the only option handling this on a per-device basis
>>
Hi Finn,
Am 11.05.2018 um 15:28 schrieb Finn Thain:
> On Fri, 11 May 2018, Michael Schmitz wrote:
>
>>>> Which begs the question: why can' you set up all Nubus bus devices'
>>>> DMA masks in nubus_device_register(), or nubus_add_board()?
>>>
&g
Hi Finn,
On Fri, May 11, 2018 at 11:55 AM, Finn Thain wrote:
>> > What's worse, if you do pass a dma_mask in struct
>> > platform_device_info, you end up with this problem in
>> > platform_device_register_full():
>> >
>> > if (pdevinfo->dma_mask) {
>> > /*
>> >
Hi Finn,
On Thu, May 10, 2018 at 1:25 PM, Finn Thain wrote:
> On Thu, 3 May 2018, Geert Uytterhoeven wrote:
>
>>
>> Perhaps you can add a new helper
>> (platform_device_register_simple_dma()?) that takes the DMA mask, too?
[...]
> To actually hoist the dma mask setup out of existing platform driv
Hi Greg,
Am 08.05.2018 um 19:25 schrieb Greg Kroah-Hartman:
> On Tue, May 08, 2018 at 09:07:27AM +0200, Geert Uytterhoeven wrote:
>> Hi Greg,
>>
>> On Tue, May 8, 2018 at 9:00 AM, Greg Kroah-Hartman
>> wrote:
>>> On Mon, May 07, 2018 at 09:51:12AM +1200, Micha
Martin,
On Mon, May 7, 2018 at 7:08 PM, Martin Steigerwald wrote:
> Michael Schmitz - 07.05.18, 04:40:
>> Al,
>>
>> I don't think there is USB sticks with affs on them as yet. There
>> isn't even USB host controller support for Amiga hardware (yet).
>&
Al,
I don't think there is USB sticks with affs on them as yet. There
isn't even USB host controller support for Amiga hardware (yet).
Last I tried USB on m68k (Atari, 060 accelerator) the desktop
experience was such that I'd rather not repeat that in a hurry (and
that was a simple FAT USB stick)
s driver module on a non-NuBus machine triggers the
>> > > BUG_ON(!drv->bus->p) in driver_register() because the bus does not get
>> > > registered unless MACH_IS_MAC(). Avoid this by registering the bus
>> > > unconditionally using postcore_initcall().
>
Hi Geert,
Am 04.05.2018 um 19:24 schrieb Geert Uytterhoeven:
> Hi Michael,
>
>>> Yes, that would be useful. The other assumption could be that
>>> platform devices always allow an all-0xff dma mask.
>>
>> That's not always true (Atari NCR5380 SCSI and floppy would use a 24
>> bit DMA mask). We u
Hi Christoph,
On Thu, May 3, 2018 at 8:51 PM, Christoph Hellwig wrote:
> On Thu, May 03, 2018 at 10:46:56AM +0200, Geert Uytterhoeven wrote:
>> Perhaps you can add a new helper (platform_device_register_simple_dma()?)
>> that takes the DMA mask, too?
>> With people setting the mask to kill the WA
Hi Geert,
test results at https://bugzilla.kernel.org/show_bug.cgi?id=43511
indicate the RDB parser bug is fixed by the patch given there, so if
Martin now submits the patch, all should be well?
(MSDOS partition support is not the only one with limitations - the
SGI partition parser also uses int
hang on 68030 (but not on 68040).
>
> Michael Schmitz also notices strange things with ioremap() on '030.
>
>> There's no need to call ioremap() for the SWIM address range, as it lies
>> within the usual IO device region at 0x5000 , which is already mapped.
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 09:30:33
the race by disabling interrupts in get_reg().
Tested on m68k (Atari Falcon, and ARAnyM emulator).
Kudos to Geert Uytterhoeven for helping to trace this race.
Signed-off-by: Michael Schmitz
---
drivers/char/random.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --gi
Martin,
looks good to me, so:
Reviewed-By: Michael Schmitz
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
Hi Finn,
Am 01.02.2017 um 21:40 schrieb Finn Thain:
>
> On Fri, 27 Jan 2017, Michael Schmitz wrote:
>
>> Am 26.01.2017 um 21:47 schrieb Finn Thain:
>>
>>> This would imply CPU overhead that is half of that which mac_scsi
>>> incurs. That's the be
been tested as well.
No change in the weird behaviour of my SCSI-SATA adapter, but perhaps
that wasn't unexpected.
Targets: Disks Seagate ST34520W and IBM DORS-32160W, CD-ROM Plextor PX-40TS.
Tested-by: Michael Schmitz
>
>
> Finn Thain (6):
> ncr5380: Shorten host info str
Hi Finn,
Am 26.01.2017 um 21:47 schrieb Finn Thain:
>> I hadn't considered that. Can PDMA for Falcon SCSI coexist with
>> interrupt-using DMA for TT SCSI in the same driver (i.e. as runtime
>> options)?
>
> Sure, why not?
>
>> How much overhead and latency would polling for DMA completion ad
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 review/test please?
>
> Pretty plea
Hi Finn,
Am 21.01.2017 um 20:37 schrieb Finn Thain:
>> The MFP interrupt in question is the same as the one used by IDE
>> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out
>> where the interrupt originated.
>
> I thought you said the driver you're testing does not use any
Hi Finn,
Am 15.01.2017 um 17:42 schrieb Finn Thain:
>> No, we can't check either FDC or SCSI interrupts (or indeed any chip
>> registers) without touching the ST-DMA. The moment we select a FDC or
>> SCSI register for read, DMA is terminated no questions asked.
>>
>
> Perhaps we can convert DM
Hi Finn,
Am 15.01.2017 um 12:47 schrieb Finn Thain:
> For the sake of discussion, I'll assume that the FDC driver will not
> be using DMA. (Perhaps FDC and SCSI can share the ST-DMA chip, using
> the present locking mechanism, but it would not simplify things much:
> when IDE no longer participat
Hi Finn,
Am 13.01.2017 um 15:33 schrieb Finn Thain:
>> The case I'm worried about is both IDE and SCSI raising an interrupt. We
>> don't currently mask the IDE/ST-DMA interrupt so a stacked interrupt
>> must be processed in the same pass as the initial interrupt or it will
>> get dropped. We'd
Bartlomiej,
>> How is polling implemented in libata? Sleeping for something
>> approximating the average seek latency shouldn't hurt but spinning
>> wont be acceptable for a low performance single CPU architecture like
>> the Falcon.
>
> You can find actual implementation in libata-sff.c.
>
> Ple
Hi Bartlomiej,
thanks for caring to support our legacy PATA systems!
On Sat, Dec 31, 2016 at 3:01 AM, Bartlomiej Zolnierkiewicz
wrote:
> Hi,
>
> This patchset adds m68k/Atari Falcon PATA support to libata.
> The major difference in the new libata's pata_falcon host
> driver when compared to lega
Hi Geert,
Am 09.12.2016 um 01:22 schrieb Geert Uytterhoeven:
> On Wed, Dec 7, 2016 at 11:36 PM, Finn Thain
> wrote:
>> On Wed, 7 Dec 2016, Geert Uytterhoeven wrote:
>>> - Convert from printk() to pr_*(),
>>> - Add missing continuations, to fix user-visible breakage,
>>> - Drop useless WARN
t; scsi/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
Finn,
tested successfully on Atari Falcon, so:
Tested-by: Michael Schmitz
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
> DMA algorithm. This res
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 mode register, such that r
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
Cheers,
Michael
Am 22.12.15 um 14:17 schrieb
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 co
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
>>>
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 pr
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
00 00 00 00 ||
That video mode is indeed the one set in the NVRAM (by ARAnyM config,
if running emulated)
Cheers,
Michael
On Sun, Jul 26, 2015 at 1:19 PM, Finn Thain wrote:
>
> On Sun, 26 Jul 2015, Michael Schmitz wrote:
>
>> Hi Finn,
>>
>> F
||
0030 de 21 |.!|
0032
d640bf7d535b54e39582fabdc016d7ca /dev/nvram
d640bf7d535b54e39582fabdc016d7ca /tmp/nvram
Happy to help ...
Cheers,
Michael
On Sat, 25 Jul 2015, Michael Schmitz wrote:
Hi Christian,
good to know this
hristian T. Steigies:
Moin,
On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:
here's what Finn asked me to run as tests:
# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/
Hi Christian,
here's what Finn asked me to run as tests:
# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram >> nvram.out
What you sent so far looks OK.
> On Wed, 22 Jul 2015, Michael Schmitz wrote:
>>
>> > Hi Finn,
>> >
>> > I'm afraid I cannot test anything on Atari hardware at present - my
>> > Falcon ate it's IDE disk partition table with all the fun that entails.
>>
>>
Hi Finn,
I'm afraid I cannot test anything on Atari hardware at present - my
Falcon ate it's IDE disk partition table with all the fun that entails.
Haven't even begun to try and recover that yet.
If you send a patch I could build a kernel and send that to Christian
for testing (if he's got
Hi Geert
If CONFIG_VT=n:
arch/m68k/atari/built-in.o: In function `atari_keyboard_interrupt':
atakeyb.c:(.text+0x1846): undefined reference to `keyboard_tasklet'
atakeyb.c:(.text+0x1852): undefined reference to `keyboard_tasklet'
Has keyboard_tasklet gone for good, or just been conditionaliz
Acked-by: Michael Schmitz
On Mon, May 5, 2014 at 5:35 PM, Finn Thain wrote:
>
> Signed-off-by: Finn Thain
> Cc: Michael Schmitz
>
> ---
>
> As requested:
> http://marc.info/?l=linux-arm-kernel&m=139853302724112&w=2
>
> diff --git a/MAINTAINERS b/MAINT
Hi James,
Perhaps Michael and Sam would be interested in sharing the role, for atari
and sun3 NCR5380 drivers (?)
If you insist ...
(kidding - I"m 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
Finn,
On Tue, Apr 29, 2014 at 2:22 PM, Finn Thain 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 patch to add you to
Acked-by: MIchael Schmitz
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
---
drivers/scsi/atari_scsi.h | 93
1 - 100 of 130 matches
Mail list logo
