Thorsten,
>> No need for the #ifdef CONFIG_Q40 - Q40 is the only m68k subarch that builds
>> the parport_pc module (which includes parport.h), IIRC. Is that correct,
>> Thorsten?
>
> The header is included outside of Q40. There is no Q40 kernel
> in Debian (yet). So, no.
OK, so it's the Amiga use
Hi,
The same .config file, also report the compiling error below:
drivers/i2c/busses/i2c-ocores.c:81:2: error: implicit declaration of function
‘iowrite8’ [-Werror=implicit-function-declaration]
drivers/i2c/busses/i2c-ocores.c:86:2: error: implicit declaration of function
‘iowrite16’ [-Werror
> I am attempting to cross-compile a 2.4 kernel for a PowerPC arch on an
> Intel machine, of which I have Debian 2.2 installed. I have successfully
> compiled a 2.4test9 kernel, but I got the following error message the first
> time I compiled (it failed due to this):
>
> powerpc-unknown-linux-g
> > Would this patch help?
> >
> > --- drivers/input/keybdev.c.org Thu Nov 2 10:13:39 2000
> > +++ drivers/input/keybdev.c Thu Nov 2 10:19:43 2000
> > @@ -36,7 +36,7 @@
> > #include
> > #include
> >
> > -#if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(__alpha__) ||
>defined
> From: Geert Uytterhoeven <[EMAIL PROTECTED]>
>
> m68k/mac: Make mac_hid_mouse_emulate_buttons() declaration visible
With buttons emulation being available via uinput event devices, do we
still need the kernel mouse button emulation? At least on powerpc, it was
declared deprecated long ago ...
A
> > Anyone using mouseemu on m68k Mac?
>
> Yes, and on powermac too. It provides the paste key for gpm and I'm quite
> fond of it. But if there's a better alternative, I'll happily try it
> instead.
Too much overhead on m68k? On powermac it never gave me trouble, but I was
surprised to hear people
TED]>
> Cc: Dmitry Torokhov <[EMAIL PROTECTED]>
> Cc: Michael Schmitz <[EMAIL PROTECTED]>
Ack, Ack ...
Thanks, Geert! Can't wait to get my Falcon back outta the container ...
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&qu
Hi,
thanks for catching this ...
> This patch fixes the following build error:
>
> <-- snip -->
>
> ...
> MODPOST 25 modules
> ERROR: "atari_keyb_init" [drivers/input/mouse/atarimouse.ko] undefined!
> ERROR: "atari_keyb_init" [drivers/input/keyboard/atakbd.ko] undefined!
> make[2]: *** [__mod
On Sat, 18 Nov 2006, Adrian Bunk wrote:
> This patch removes video drivers that:
> - had already been marked as BROKEN in 2.6.0 three years ago and
> - are still marked as BROKEN.
>
> These are the following drivers:
> - FB_CYBER
> - FB_VIRGE
> - FB_RETINAZ3
> - FB_ATARI
FB_ATARI has just been re
> > > > + // need to init core driver if not already done so
> > > > + if (atari_keyb_init())
> > >
> > > Memory leak
> >
> > How so? If the core has been initialized already this will just return ...
> >
>
> You just allocated atakbd_dev. If atari_keyb_init() fails you leak it.
I see.
> > > `default y if M68K && SYSV_FS'
> >
> > I prefer `default y if VME'.
> >
>
> Incidentally, what is the problem you have with SYSV68_PARTITION ?
> On my i586 machine, code size is 434 bytes for sysv68.o + 4 bytes more in
> check.c
Traditionally, we have always been very conservative about en
On Wed, 9 May 2007, Russell King wrote:
> drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH'
> refers to undefined symbol 'UCC_FAST'
> drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol
> 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE
> > > +#define BUS_ATARI0x1B
> >
> > Is this really a separate bus? Should't we have a BUS_ONBOARD or so
> > instead?
>
> BUS_HOST shoudl fit the bill.
OK, I'll use that one.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
> > > Update the atari fb to 2.6 by Michael Schmitz,
> >
> > Finally :-). That leaves only pm3fb that needs porting.
> >
> > It still contains remnants of 2.4 code though, ie, FBCON_HAS_*, but
> > that's minor.
>
> Yeah!!! Its a good step forward
On Tue, 1 May 2007, Christoph Hellwig wrote:
> What's the reason for splitting this up? Things would be a quite a bit
> simpler if all the code was directly in atakeyb.c.
Simple: I assumed that keeping the input driver code with the other input
stuff was the Right Thing. I can move everything ba
> > > What's the reason for splitting this up? Things would be a quite a bit
> > > simpler if all the code was directly in atakeyb.c.
> >
> > Simple: I assumed that keeping the input driver code with the other input
> > stuff was the Right Thing. I can move everything back to atakeyb.c if
> > that
> > +static unsigned char rep_scancode;
> > +static struct timer_list atakeyb_rep_timer = {
> > + .function = atakeyb_rep,
> > +};
>
> Is there a problem with repeat implementation in input core that
> requres custom-made repeater here?
Apparently not - the homebrew repeater has not been act
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
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.
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
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
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
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
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
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
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 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 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 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,
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
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,
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
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
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
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
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
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
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
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 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,
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 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 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
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
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
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
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
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
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
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
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 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 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
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 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
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/
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
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,
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 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,
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:
Thomas,
This is a temporary hack to allow timer based polling of the
Atari ROM port network and USB cards only. Suggestions on how to
properly handle this in the normal interrupt framework are most
welcome.
So you're polling devices which have no hardware interrupt from the
timer interrupt. Of
Arnd
Cc: Andrew Morton
Cc: David S. Miller
Cc: Geert Uytterhoeven
Cc: Greg Kroah-Hartman
Cc: Ingo Molnar
Cc: "James E.J. Bottomley"
Cc: Jens Axboe
Cc: Karsten Keil
Cc: Mauro Carvalho Chehab
Cc: Michael Schmitz
Cc: Peter Zijlstra
Cc: linux-atm-gene...@lists.sourceforge.net
C
_lock 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
Cc: Michael Schmitz
Cc: Geert Uytterhoeven
Cc: James E.J. Bottomley
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/atari_scsi.c
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
Thomas,
Does the following patch solve the problem? You need to call
irq_set_status_flags(irq, IRQ_IS_POLLED);
when setting up the interrupt controller for those polled interrupt
lines.
Your patch works just fine, thanks.
I suppose setting the flag can be done in the corresponding irq
Thomas,
Is there an easy to setup/use emulator around on which I could try to
dig into that myself?
I believe Geert uses ARAnyM for his tests of m68k kernels on emulators
- it is reasonably easy to set up and use. I've used it to debug
problems we had with the SLUB allocator two years ago.
Thomas,
Finally found the issue. The patch below fixes the problem here. The
little missing detail is, that I zapped GET_CURRENT() assuming blindly
that this is only needed for the preempt_count hackery. But in fact
the world and some more depends on it which leads to interesting
explosions.
T
Thomas,
I suppose setting the flag can be done in the corresponding irq
startup
function, instead of when setting up the irq controller?
irq_startup() is called with irq_desc->lock held and
irq_set_status_flags() wants desc->lock as well. Deadlock
Thanks, point taken.
And no, you don't wa
Geert,
does your fiddling with memory blocks in bootinfo now result in kernels
being possible to boot in FastRAM?
Cheers,
Michael
nf_init() uses virt_to_phys(), which depends on m68k_memoffset being
set and
module_fixup() having been called, but this is only done in
paging_init().
Hi Geert,
On Fri, Oct 18, 2013 at 9:29 AM, Michael Schmitz
wrote:
does your fiddling with memory blocks in bootinfo now result in
kernels
being possible to boot in FastRAM?
No, I only played with the start address of ST-RAM.
Probably you can run a kernel in FastRAM with some minor tweaks
Acked-by: Michael Schmitz
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. For example, they
Acked-by: Michael Schmitz
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. For example, they
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
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
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
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
Cc: linux-kernel@vger.kernel.org
---
drivers
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 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
> 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 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.
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/
||
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
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
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
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,
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,
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 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
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
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
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
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
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
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
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 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,
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
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 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
1 - 100 of 130 matches
Mail list logo
