Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

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

Re: [PATCH] scsi/NCR5380: Remove in_interrupt() test

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: https

Re: [PATCH] scsi/atari_scsi: Fix race condition between .queuecommand and EH

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

Re: [PATCH] scsi/NCR5380: Reduce NCR5380_maybe_release_dma_irq() call sites

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

Re: [PATCH 11/13] m68k/mm: make node data and node setup depend on CONFIG_DISCONTIGMEM

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

Re: [PATCH] ide/falconide: Fix module unload

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

Re: [PATCH v2] ide/macide: Convert Mac IDE driver to platform driver

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,

Re: [PATCH] ide/macide: Convert Mac IDE driver to platform driver

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

Re: [PATCH v2 2/7] scsi: NCR5380: Always re-enable reselection interrupt

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

Re: [PATCH] NCR5380: Support chained sg lists

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

Re: [PATCH v2 2/7] scsi: NCR5380: Always re-enable reselection interrupt

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

Re: [PATCH v2 2/7] scsi: NCR5380: Always re-enable reselection interrupt

lls 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 ++-- 1 fi

Re: [PATCH] NCR5380: Support chained sg lists

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 --- drivers

Re: [PATCH 5/7] scsi: mac_scsi: Fix pseudo DMA implementation, take 2

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

Re: linux-next: build failure after merge of the ecryptfs tree

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 name? I've got

Re: linux-next: build failure after merge of the ecryptfs tree

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

Re: [PATCH v2] scsi: NCR5380: Mark expected switch fall-through

bel 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/NCR5

Re: [v4,1/9] net-next: phy: new Asix Electronics PHY driver

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, Michael Schmitz wrote

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

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

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

in 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

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

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

Re: [PATCH v8 01/25] scsi/atari_scsi: Don't select CONFIG_NVRAM

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 @@

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

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

Re: [RFC PATCH v2 09/14] m68k: hp300: Remove hp300_gettimeoffset()

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

Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

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

Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

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

Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

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 platform

Re: [RFC PATCH v2 07/14] m68k: atari: Convert to clocksource API

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 platform

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 ARAnyM

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 ARAnyM

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 appear to work

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 appear to work

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 different userland

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 different userland

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 to clocksource

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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 to clocksource

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [RFC PATCH 06/13] m68k: Drop ARCH_USES_GETTIMEOFFSET

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

Re: [PATCH] ata: add Buddha PATA controller driver

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

Re: [PATCH] ata: add Buddha PATA controller driver

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

Re: [PATCH] ata: add Buddha PATA controller driver

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

Re: [PATCH] ata: add Buddha PATA controller driver

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

Re: [PATCH] ata: add Buddha PATA controller driver

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,

Re: [PATCH] ata: add Buddha PATA controller driver

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,

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

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 around

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

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 around

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

. 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 essential

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

. 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 essential

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

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

Re: [PATCH AUTOSEL 4.18 24/58] Input: atakbd - fix Atari CapsLock behaviour

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

Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled

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

Re: [PATCH v3 3/7] drivers: parisc: Avoids building driver if CONFIG_PARISC is disabled

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

Re: moving affs + RDB partition support to staging?

. 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 supports more recent partition formats, all the better. T

Re: moving affs + RDB partition support to staging?

. 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 supports more recent partition formats, all the better. T

Re: moving affs + RDB partition support to staging?

oing 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 from an old disk 80 GB disk are still recognized OK). That"s only bee

Re: moving affs + RDB partition support to staging?

oing 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 from an old disk 80 GB disk are still recognized OK). That"s only bee

Re: moving affs + RDB partition support to staging?

ough 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 that doing 32 b

Re: moving affs + RDB partition support to staging?

ough 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 that doing 32 b

Re: moving affs + RDB partition support to staging?

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 >>

Re: moving affs + RDB partition support to staging?

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 >>

Re: moving affs + RDB partition support to staging?

p 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 > into a gordian knot. > > {^_^} > > On

Re: moving affs + RDB partition support to staging?

p 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 > into a gordian knot. > > {^_^} > > On

Re: moving affs + RDB partition support to staging?

19902322 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 results at https

Re: moving affs + RDB partition support to staging?

19902322 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 results at https

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

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 given there

Re: moving affs + RDB partition support to staging? (was: Re: Moving unmaintained filesystems to staging)

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 given there

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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: >>> > On

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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: >>> > On

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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 - does link

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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 - does link

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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 >>

Re: [RFC PATCH] m68k: set dma and coherent masks for Macintosh SONIC based ethernet

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 >>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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 >> witho

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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 >> witho

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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()? >>> >>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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()? >>> >>

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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) { >> >

Re: [PATCH net] macmace: Set platform device coherent_dma_mask

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) { >> > /* >> >

Re: [PATCH net] macmace: Set platform device coherent_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

Re: [PATCH net] macmace: Set platform device coherent_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

Re: [PATCH] nubus: Unconditionally register bus type

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 >> <gre...@linuxfoundation.org> wrote: >>> On Mon,

Re: [PATCH] nubus: Unconditionally register bus type

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,

Re: moving affs + RDB partition support to staging?

Martin, On Mon, May 7, 2018 at 7:08 PM, Martin Steigerwald <mar...@lichtvoll.de> 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 hardw

Re: moving affs + RDB partition support to staging?

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). >> >&g

  1   2   3   >