On 17/11/18 5:44 am, Geert Uytterhoeven wrote:
Hi Linus,
On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij wrote:
On Fri, Nov 16, 2018 at 1:31 AM Finn Thain wrote:
On Wed, 14 Nov 2018, Linus Walleij wrote:
Apart from this (which is the most important step!) I think the custom
LED heartbeat c
Hi Linus,
On Fri, Nov 16, 2018 at 10:33 PM Linus Walleij wrote:
> On Fri, Nov 16, 2018 at 8:44 PM Geert Uytterhoeven
> wrote:
> > On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij
> > wrote:
> > > I mean that whole thing should go away by abstracting those LEDs
> > > (for the systems that have t
On Fri, Nov 16, 2018 at 8:44 PM Geert Uytterhoeven wrote:
> On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij
> wrote:
> > I mean that whole thing should go away by abstracting those LEDs
> > (for the systems that have them) using the struct led_classdev,
> > populating a proper platform device fo
Hi Linus,
On Fri, Nov 16, 2018 at 12:13 PM Linus Walleij wrote:
> On Fri, Nov 16, 2018 at 1:31 AM Finn Thain wrote:
> > On Wed, 14 Nov 2018, Linus Walleij wrote:
> > > Apart from this (which is the most important step!) I think the custom
> > > LED heartbeat code in kernel/time.c needs to be rep
On Fri, Nov 16, 2018 at 1:31 AM Finn Thain wrote:
> On Wed, 14 Nov 2018, Linus Walleij wrote:
> > Apart from this (which is the most important step!) I think the custom
> > LED heartbeat code in kernel/time.c needs to be replaced with a standard
> > drivers/leds driver for each LED using the "hea
On Wed, 14 Nov 2018, Linus Walleij wrote:
> > >
> > > You can see those patches here,
> > > https://github.com/fthain/linux/commits/mac68k-queue/
>
> This is looking very good. FWIW:
> Acked-by: Linus Walleij
>
Thanks for your review.
> Apart from this (which is the most important step!) I th
On Sat, Nov 10, 2018 at 10:47 PM Arnd Bergmann wrote:
> On Fri, Nov 9, 2018 at 12:42 AM Finn Thain wrote:
> > On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
> > > > > The example I gave was GENERIC_CLOCKEVENTS on m68, which is
> > > > > supported on most but not all machines there.
> > > >
> > >
On Mon, 12 Nov 2018, Michael Schmitz wrote:
> I'm wondering if disabling interrupts really is required when updating
> the ticks counter in mfp_timer_handler, or whether READ_ONCE() and
> WRITE_ONCE() would work as well.
>
I get the impression from Documentation/core-api/atomic_ops.rst that th
Hi Finn,
Am 12.11.18 um 17:34 schrieb Finn Thain:
> On Mon, 12 Nov 2018, Michael Schmitz wrote:
>
>> That's ultimately for Geert to decide - I'll yet have to look at your
>> mac patches to even get a vague idea what this conversion involves, but
>> I can certainly test whatever you came up with
On Mon, 12 Nov 2018, Michael Schmitz wrote:
>
> That's ultimately for Geert to decide - I'll yet have to look at your
> mac patches to even get a vague idea what this conversion involves, but
> I can certainly test whatever you came up with for Mac on Atari.
>
Thanks. I'll send out the latest
Thanks Finn,
Am 09.11.2018 um 12:42 schrieb Finn Thain:
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
The example I gave was GENERIC_CLOCKEVENTS on m68, which is
supported on most but not all machines there.
That suggests that the removal of just those machines would suffice
(as opposed to
On Fri, Nov 9, 2018 at 12:42 AM Finn Thain wrote:
> On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
> > > > The example I gave was GENERIC_CLOCKEVENTS on m68, which is
> > > > supported on most but not all machines there.
> > >
> > > That suggests that the removal of just those machines would suffi
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
> > >
> > > The example I gave was GENERIC_CLOCKEVENTS on m68, which is
> > > supported on most but not all machines there.
> >
> > That suggests that the removal of just those machines would suffice
> > (as opposed to the removal of the entire arch
On Mon, 29 Oct 2018, Arnd Bergmann wrote:
> [...] The real question that we tried to resolve is how we can more
> generally find out whether a driver is still being used or not when it
> gets in the way of some API conversion. [...]
I think you have to show that the driver or platform or arch h
On Mon, Oct 29, 2018 at 2:58 AM Greg Ungerer wrote:
> I have been working on and maintaining parts of m68k for a long time,
> and I was not aware that there was a number of problem areas that are
> causing real pain. Maybe a friendly email from subsystem maintainers that
> see issues would go a lo
Hi Arnd,
On 28/10/18 1:54 am, Arnd Bergmann wrote:
On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven wrote:
Hi Arnd,
https://lwn.net/Articles/769468/ wrote:
For example, the m68k architecture uses a number of internal APIs that no
other
architecture needs at this point; removing that ar
On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:
> > >
> > > The example I gave was GENERIC_CLOCKEVENTS on m68, which is
> > > supported on most but not all machines there.
> >
> > That suggests that the removal of just those machines would suffice
> > (as opposed to the removal of the entire arch
[ Wow, I hadn't expected such a heated discussion, I just wanted to
know which code
needed fixes... ]
On Sun, Oct 28, 2018 at 8:00 AM Finn Thain wrote:
> On Sat, 27 Oct 2018, Arnd Bergmann wrote:
> > On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven
> > wrote:
> > > https://lwn.net/Articles/
On Sat, 27 Oct 2018, Arnd Bergmann wrote:
> On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven
> wrote:
> >
> > Hi Arnd,
> >
> > https://lwn.net/Articles/769468/ wrote:
> > > For example, the m68k architecture uses a number of internal APIs that
> > > no other
> > > architecture needs at this
On Sat, 27 Oct 2018, Geert Uytterhoeven wrote:
> Hi Arnd,
>
> https://lwn.net/Articles/769468/ wrote:
> > For example, the m68k architecture uses a number of internal APIs
> > that no other architecture needs at this point; removing that
> > architecture would enable removing the APIs as well
On Sat, 27 Oct 2018, John Paul Adrian Glaubitz wrote:
> This stuff is so getting annoying. I don't understand why all of a
> sudden there is such a big urge to kick everything out that is old. Is
> the Linux kernel supposed to be an x86-only project?
>
Some maintainers don't like mature code.
On Sat, Oct 27, 2018 at 5:02 PM Geert Uytterhoeven wrote:
>
> Hi Arnd,
>
> https://lwn.net/Articles/769468/ wrote:
> > For example, the m68k architecture uses a number of internal APIs that no
> > other
> > architecture needs at this point; removing that architecture would enable
> > removing
>
On 10/27/18 5:01 PM, Geert Uytterhoeven wrote:
>> This kind of approach has worked well in the Debian community
>
> Right, Debian stopped supporting m68k a long time ago ;-)
This stuff is so getting annoying. I don't understand why all of a sudden there
is
such a big urge to kick everything out
Hi Arnd,
https://lwn.net/Articles/769468/ wrote:
> For example, the m68k architecture uses a number of internal APIs that no
> other
> architecture needs at this point; removing that architecture would enable
> removing
> the APIs as well
and
> Ted Ts'o suggested that an ultimatum could be ma
24 matches
Mail list logo
