On Nov 30 2018, Andreas Schwab wrote:
> [0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
> 20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
> [0.00] Saving 190 bytes of bootinfo
> [0.00] console [debug0] enabled
> [0.00] Atari hardware found:
[0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
[0.00] Saving 190 bytes of bootinfo
[0.00] console [debug0] enabled
[0.00] Atari hardware found: VIDEL STDMA-SCSI ST_MFP YM2149 PCM CODEC
DSP56K SCC
Andreas,
Am 01.12.2018 um 11:23 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Must be a new kind of monster kernel that wouldn't fit inside 14 MB.
There's way more than the kernel that must fit in 14 MB.
I realize that. I only said to try and load the kernel to ST-RAM,
Andreas,
Am 01.12.2018 um 10:12 schrieb Andreas Schwab:
On Nov 30 2018, Andreas Schwab wrote:
[0.00] Linux version 4.19.0 (andr...@igel.home) (gcc version 8.1.1
20180712 (GCC)) #3 Fri Nov 30 20:53:33 CET 2018
[0.00] Saving 190 bytes of bootinfo
[0.00] console
On Dez 01 2018, Michael Schmitz wrote:
> Doesn't work for me - with or without -s option I get the same
What -s option?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Am 01.12.2018 um 12:09 schrieb Andreas Schwab:
On Dez 01 2018, Michael Schmitz wrote:
Doesn't work for me - with or without -s option I get the same
What -s option?
In the LILO section:
Args = -s root=/dev/hda1 debug=par stram_pool=2048k
Cheers,
Michael
In order to comply with the CoC, replace with a hug.
Signed-off-by: Jarkko Sakkinen
---
arch/m68k/include/asm/sun3ints.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68k/include/asm/sun3ints.h b/arch/m68k/include/asm/sun3ints.h
index 309d6e6a1374..90206bcfebb6
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
>
> In order to comply with the CoC, replace with a hug.
Heh. I support the replacement of the stronger language, but I find
"hug", "hugged", and "hugging" to be very weird replacements. Can we
bikeshed this to "heck", "hecked", and
On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> In order to comply with the CoC, replace with a hug.
>
> -/* master list of VME vectors -- don't fuck with this */
> +/* master list of VME vectors -- don't hug with this */
Never in my dreams would I have expected that the dystopia predicted
in
On Fri, 30 Nov 2018, Kees Cook wrote:
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
In order to comply with the CoC, replace with a hug.
I hope this is some kind of joke. How would anyone get offended by reading
technical comments? This is all beyond me...
Thanks,
Davidlohr
On 11/30/18 8:40 PM, Kees Cook wrote:
> Better yet, since it's only 17 files, how about doing context-specific
> changes? "This API is terrible", "Hateful interface", "Don't touch my
> freakin' code", "What in the world were they thinking?" etc?
Or just leave it as is because we're all grown up
On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>> wrote:
>>>
>>> In order to comply with the CoC, replace with a hug.
>
> I hope this is some kind of joke. How would anyone get offended by reading
>
On 30/11/2018 20:40, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
>>
>> In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be very weird
From: Davidlohr Bueso
Date: Fri, 30 Nov 2018 11:56:52 -0800
> I hope this is some kind of joke.
Whether or not it is a joke, it is censorship.
And because of that I have no intention to apply any patches like this
to any code I am in charge of.
Am 01.12.2018 um 09:12 schrieb Jens Axboe:
On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
On Fri, 30 Nov 2018, Kees Cook wrote:
On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
wrote:
In order to comply with the CoC, replace with a hug.
I hope this is some kind of joke. How would
From: Jens Axboe
Date: Fri, 30 Nov 2018 13:12:26 -0700
> On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
>> On Fri, 30 Nov 2018, Kees Cook wrote:
>>
>>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
>>> wrote:
In order to comply with the CoC, replace with a hug.
>>
>> I hope
From: Abuse
Date: Fri, 30 Nov 2018 20:39:01 +
> I assume I will now be barred.
Perhaps, but not because you said fuck. It would be because you're
intentionally creating a disturbance on the list and making it more
difficult for developers to get their work done and intentionally
creating a
On Fri, 30 Nov 2018 20:39:01 +
Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> >
On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> On Fri, 30 Nov 2018, Kees Cook wrote:
>
> > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > wrote:
> > >
> > > In order to comply with the CoC, replace with a hug.
>
> I hope this is some kind of joke. How would
On Fri, Nov 30, 2018 at 08:44:24PM +0100, John Paul Adrian Glaubitz wrote:
> On 11/30/18 8:27 PM, Jarkko Sakkinen wrote:
> > In order to comply with the CoC, replace with a hug.
> >
> > -/* master list of VME vectors -- don't fuck with this */
> > +/* master list of VME vectors -- don't hug
On Fri, 2018-11-30 at 12:55 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC, replace
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 11:56:52AM -0800, Davidlohr Bueso wrote:
> > On Fri, 30 Nov 2018, Kees Cook wrote:
> >
> > > On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> > > wrote:
> > > >
> > > > In order to comply with the CoC,
On Fri, 30 Nov 2018 12:55:21 -0800
Jarkko Sakkinen wrote:
> This a direct quote from the CoC:
>
> "Harassment includes the use of abusive, offensive or degrading
> language, intimidation, stalking, harassing photography or recording,
> inappropriate physical contact, sexual imagery and
On Fri, Nov 30, 2018 at 11:40:17AM -0800, Kees Cook wrote:
> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> wrote:
> >
> > In order to comply with the CoC, replace with a hug.
>
> Heh. I support the replacement of the stronger language, but I find
> "hug", "hugged", and "hugging" to be
On Fri, Nov 30, 2018 at 09:09:48PM +0100, John Paul Adrian Glaubitz wrote:
> Or just leave it as is because we're all grown up and don't freak out
> when a piece of text contains the word "fuck".
>
> I still don't understand why people think that the word "fuck" is what
> would keep certain
On Fri, Nov 30, 2018 at 09:31:13PM +0100, Matthias Brugger wrote:
> Like John I don't think that the word "fuck" is something we have to ban from
> the source code, but I don't care too much. Anyway, please don't change it to
> something like heck as it might be difficult for non-english speaker
On Fri, Nov 30, 2018 at 12:35:07PM -0800, David Miller wrote:
> From: Jens Axboe
> Date: Fri, 30 Nov 2018 13:12:26 -0700
>
> > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> >> On Fri, 30 Nov 2018, Kees Cook wrote:
> >>
> >>> On Fri, Nov 30, 2018 at 11:27 AM Jarkko Sakkinen
> >>> wrote:
>
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:42:33 -0800
> Can you tell how the CoC should be interpreted then?
Regardless of what I think, as others have showen the CoC explicitly
does not apply to existing code.
From: Jarkko Sakkinen
Date: Fri, 30 Nov 2018 13:44:05 -0800
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
>> No because use of what some people consider to be bad language isn't
>> necessarily abusive, offensive or degrading. Our most heavily censored
>> medium is TV and
On 11/30/18 2:47 PM, David Miller wrote:
> From: Jarkko Sakkinen
> Date: Fri, 30 Nov 2018 13:42:33 -0800
>
>> Can you tell how the CoC should be interpreted then?
>
> Regardless of what I think, as others have showen the CoC explicitly
> does not apply to existing code.
And with that, can we
On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > No because use of what some people consider to be bad language
> > isn't necessarily abusive, offensive or degrading. Our most
> > heavily censored medium is TV and
On Fri, 2018-11-30 at 13:54 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 01:48:08PM -0800, David Miller wrote:
> > From: Jarkko Sakkinen
> > Date: Fri, 30 Nov 2018 13:44:05 -0800
> >
> > > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > > No because use of what
On Fri, Nov 30, 2018 at 01:57:49PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 13:44 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 01:01:02PM -0800, James Bottomley wrote:
> > > No because use of what some people consider to be bad language
> > > isn't necessarily abusive,
On Fri, 30 Nov 2018 14:12:19 -0800
Jarkko Sakkinen wrote:
> As a maintainer myself (and based on somewhat disturbed feedback from
> other maintainers) I can only make the conclusion that nobody knows what
> the responsibility part here means.
>
> I would interpret, if I read it like at lawyer
On Fri, 2018-11-30 at 14:12 -0800, Jarkko Sakkinen wrote:
[...]
> I pasted this already to another response and this was probably the
> part that ignited me to send the patch set (was a few days ago, so
> had to revisit to find the exact paragraph):
I replied in to the other thread.
>
On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen wrote:
>
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobody knows what
> > the
On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
[...]
> > Have you read Documentation/process/code-of-conduct-
> > interpretation.rst?
> > As has been pointed out, it contains a clear answer to how things
> > should be
On Fri, Nov 30, 2018 at 02:30:45PM -0800, James Bottomley wrote:
> On Fri, 2018-11-30 at 14:26 -0800, Jarkko Sakkinen wrote:
> > On Fri, Nov 30, 2018 at 03:14:59PM -0700, Jonathan Corbet wrote:
> [...]
> > > Have you read Documentation/process/code-of-conduct-
> > > interpretation.rst?
> > > As
On Fri, 30 Nov 2018, Jarkko Sakkinen wrote:
> > Never in my dreams would I have expected that the dystopia predicted
> > in "Demolition Man" would ever come true and that so early.
> >
> > I'm waiting for the automatic punishment machines which spit out tickets
> > whenever someone in their
On Fri, Nov 30, 2018 at 02:40:19PM -0800, Jarkko Sakkinen wrote:
> Got you... Well I now read the 2nd amendment now through, and yeah, kind
> of way I work/function anyway.
Ugh, looked up the word from dictionary for something that makes
additions to some guidelines because did not know the
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
- Use type u32 for tick counter.
---
arch/m68k/include/asm/mvme147hw.h | 1 -
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
- Use type u32 for tick counter.
---
arch/m68k/hp300/time.c | 37
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.
Suggested-by: Thomas Gleixner
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
Tested-by: Stan Johnson
---
Changed since v3:
- Use clk_offset variable to track the offset when the irq check is skipped.
Changed since v2:
- Drop
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Normally the MFP timer C interrupt flag would be used to check for
timer counter wrap-around. Unfortunately, that flag gets cleared by the
MFP itself (due to automatic End-of-Interrupt mode). This means that
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v3:
- Use clk_offset variable to track the offset when the irq check is skipped.
Changed since v2:
- Don't check for timer interrupt in
Reading the timer counter races with timer overflow (and the
corresponding interrupt). This is resolved by reading the overflow
register and taking this value into account. The interrupt handler
must clear the overflow register when it eventually executes.
Suggested-by: Thomas Gleixner
Add a platform clocksource by adapting the existing arch_gettimeoffset
implementation.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
Changed since v1:
- Moved clk_total access to within the irq lock.
---
arch/m68k/mvme16x/config.c | 37 +++--
1 file
These dummy implementations are no better than
default_arch_gettimeoffset() so remove them.
Signed-off-by: Finn Thain
---
arch/m68k/apollo/config.c | 7 ---
arch/m68k/q40/config.c| 9 -
arch/m68k/sun3/config.c | 2 --
arch/m68k/sun3/intersil.c | 7 ---
This series removes "select ARCH_USES_GETTIMEOFFSET" from arch/m68k
and converts users of arch_gettimeoffset to the clocksource API.
Various bugs are fixed along the way.
Those platforms which do not actually implement arch_gettimeoffset
(apollo, q40, sun3, sun3x) use the "jiffies" clocksource by
Some platforms execute their timer handler with the interrupt priority
level set below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.
Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual
This resolves some bugs that affect VIA timer counter accesses.
Avoid lost interrupts caused by reading the counter low byte register.
Make allowance for the fact that the counter will be decremented to
0x before being reloaded.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn
Because hp300_read_clk() never checks the timer interrupt flag it may
fail to notice that the timer has wrapped, allowing the clock to jump
backwards. This is not a new problem.
This is resolved by checking the interrupt flag and, if need be,
taking wrap-around into account. The interrupt handler
The functions that implement arch_gettimeoffset are re-used by
new clocksource drivers in subsequent patches.
Signed-off-by: Finn Thain
Acked-by: Linus Walleij
---
arch/m68k/Kconfig | 1 -
arch/m68k/amiga/config.c| 3 ---
arch/m68k/atari/config.c| 2 --
On Fri, Nov 30, 2018 at 08:39:01PM +, Abuse wrote:
> On Friday, 30 November 2018 20:35:07 GMT David Miller wrote:
> > From: Jens Axboe
> > Date: Fri, 30 Nov 2018 13:12:26 -0700
> >
> > > On 11/30/18 12:56 PM, Davidlohr Bueso wrote:
> > >> On Fri, 30 Nov 2018, Kees Cook wrote:
> > >>
> > >>>
On Dez 01 2018, Michael Schmitz wrote:
> Try with the kernel loaded in ST-RAM - should not make a difference for
> ARAnyM, or does it now?
There isn't enough space there.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA
56 matches
Mail list logo
