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

Looking at functions with large stack frames across all architectures led me discovering that BUG() suffers from the same problem as fortify_panic(), which I've added a workaround for already. In short, variables that go out of scope by calling a noreturn function or __builtin_unreachable() keep

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

Hi Arnd, On Tue, Dec 19, 2017 at 12:39 PM, Arnd Bergmann wrote: > The name barrier_before_unreachable() is a bit suboptimal here, > as it fails to describe the fact that it is needed for both > __builtin_unreachable() and for calling noreturn functions. Any other > suggestions

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

On 12/19/2017 03:41 AM, Arnd Bergmann wrote: Looking at functions with large stack frames across all architectures led me discovering that BUG() suffers from the same problem as fortify_panic(), which I've added a workaround for already. In short, variables that go out of scope by calling a

Re: m68k v3.16 status update

On Tue, 19 Dec 2017, Michael Schmitz wrote: > > esp->command_block_dma is mapped at driver init time so we don't get to > chose at command submission time. When the command is submitted, ops->send_dma_cmd() can do something like this, static void zorro_esp_send_dma_cmd(struct esp *esp, u32

zorro_esp, was Re: m68k v3.16 status update

On Tue, 19 Dec 2017, Michael Schmitz wrote: > > > > > Contrary to the Mac driver, esp->command_block and > > > esp->command_block_dma are not identical addresses on Amiga. > > > > Why not make them identical, depending on the length of the tranfer? > > (Then choose PIO or DMA by testing for

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

On 12/19/2017 12:13 PM, Arnd Bergmann wrote: I suppose BUG() implies "dead end" like semantics - which ARC was lacking before ? Correct. Using __builtin_trap() here avoids the 'control reaches end of non-void function' warnings, but then makes us run into the stack size problem that I work

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

On Tue, Dec 19, 2017 at 5:57 PM, Vineet Gupta wrote: > On 12/19/2017 03:41 AM, Arnd Bergmann wrote: >> In case of ARC and CRIS, it turns out that the BUG() implementation >> actually does return (or at least the compiler thinks it does), resulting >> in lots of

Re: m68k v3.16 status update

Hi Finn, On Wed, Dec 20, 2017 at 12:01 PM, Finn Thain wrote: > On Tue, 19 Dec 2017, Michael Schmitz wrote: > >> >> esp->command_block_dma is mapped at driver init time so we don't get to >> chose at command submission time. > > When the command is submitted,

Re: m68k v3.16 status update

On Wed, 20 Dec 2017, Michael Schmitz wrote: > > I test for phase == ESP_MIP and direct to the PIO routine, I'm more pessimistic and expect short DMA transfers to fail in any phase (though in practice that may never happen). > and use the following code to fix up the transfer address there: >

zorro_esp, was: Re: m68k v3.16 status update

Hi Geert, Am 19.12.2017 um 21:19 schrieb Geert Uytterhoeven: > Hi Michael, > > On Tue, Dec 19, 2017 at 1:40 AM, Michael Schmitz wrote: >> Contrary to the Mac driver, esp->command_block and >> esp->command_block_dma are not identical addresses on Amiga. Is there >> a

Re: m68k v3.16 status update

Hi Michael, On Tue, Dec 19, 2017 at 1:40 AM, Michael Schmitz wrote: > Contrary to the Mac driver, esp->command_block and > esp->command_block_dma are not identical addresses on Amiga. Is there > a generic way to map a DMA address (i.e., physical address AFAIK) to a > kernel