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 minimalist userspace. So, it's probably time to say goodbyte to the kernel support for these platforms. Your call. Note that removing code from mainline won't help users obtain older, smaller, -stable kernel releases, free from the bug we were discussing. (The bug appeared in Linux v2.6.32.) BTW, if you did want to boot Linux on a 16 MB system, you do have some options. https://lwn.net/Articles/741494/ https://lwn.net/Articles/608945/ https://tiny.wiki.kernel.org/ Contributing to this kind of effort probably has value for IoT deployments. I suspect it also cuts a small amount of bloat from a large number of other Linux systems. I boot 4.19 on a system with 14 MB RAM - 10 MB remain for user space once the kernel loads. After remote login, 4 MB of that remain free for buffers or user code (1.5 MB swapped). That's with sysvinit - Christian tried to boot a systemd userland on his Falcon once, and ran out of memory before swap could be activated. I shouldn't say 16 or 32 MB are hopeless. And the 2.6 kernels were a lot more sluggish to my recollection. Cheers, Michael
Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset
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 minimalist userspace. > > So, it's probably time to say goodbyte to the kernel support for these > platforms. > Your call. Note that removing code from mainline won't help users obtain older, smaller, -stable kernel releases, free from the bug we were discussing. (The bug appeared in Linux v2.6.32.) BTW, if you did want to boot Linux on a 16 MB system, you do have some options. https://lwn.net/Articles/741494/ https://lwn.net/Articles/608945/ https://tiny.wiki.kernel.org/ Contributing to this kind of effort probably has value for IoT deployments. I suspect it also cuts a small amount of bloat from a large number of other Linux systems. --
Re: m68k using deprecated internal APIs?
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 for it and instantiate using > > a driver in drivers/leds/*, and the function to provide the heartbeat > > be replaced with the existing heartbeat trigger in > > drivers/leds/trigger/ledtrig-heartbeat.c assigned as default > > trigger for that LED. > > > > I think that is WAY out of the focus for your current work (which, > > by the way, is a piece of art) but more something for the m68k > > maintainers to look into. > > Just going with struct led_classdev is probably doable. Would be nice. > Going for the full monty, using leds-gpio, probably requires moving m68k > to DT. Which would not be that ... uninteresting ;-) If the line with the LED is not general purpose but an actual register bit for the LED it should not be using legs-gpio anyway. But something similar to Russells neat drivers/gpio/gpio-reg.c but for LED classdevs in drivers/leds/leds-reg.c would be a really tempting option I think. Yours, Linus Walleij
Re: m68k using deprecated internal APIs?
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 replaced with a standard
> > > drivers/leds driver for each LED using the "heartbeat" trigger as is
> > > custom these days.
> > >
> > > That should clean out another chunk of legacy time-related code.
> >
> > Are you referring to LED heartbeat code in arch/m68k/kernel/time.c?
> >
> > > I suppose you are currently keeping the call to timer_interrupt() for
> > > exactly this reason (i.e. keep the heartbeat LED blinking)?
> >
> > It would be great to have that call inlined, which the compiler can't do
> > at the moment, because timer_interrupt() is in a different compilation
> > unit (arch/m68k/kernel/time.c).
> >
> > Is there some other benefit to eliminating the call to timer_interrupt()
> > that I've overlooked?
>
> 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 for it and instantiate using
> a driver in drivers/leds/*, and the function to provide the heartbeat
> be replaced with the existing heartbeat trigger in
> drivers/leds/trigger/ledtrig-heartbeat.c assigned as default
> trigger for that LED.
>
> I think that is WAY out of the focus for your current work (which,
> by the way, is a piece of art) but more something for the m68k
> maintainers to look into.
Just going with struct led_classdev is probably doable.
Going for the full monty, using leds-gpio, probably requires moving m68k
to DT. Which would not be that ... uninteresting ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [RFC PATCH 01/13] arm: Fix mutual exclusion in arch_gettimeoffset
On Thu, Nov 15, 2018 at 03:12:17PM +1100, Finn Thain wrote: > The thread went way off-topic when Christoph took the opportunity to > suggest the removal of RPC and EBSA110. That doesn't interest me. I suspect that is the right solution - I've been trying to get 4.19 to boot on my RPC and it's proving very difficult for several reasons, not limited to the HDD seeming to be throwing the odd disk error, as well as the kernel being rather large (a 4.19 kernel is 2.7M compressed as opposed to 2.6.29 being 1.2M compressed for the equivalent configuration.) Given that memory on the RPC is not contiguous, that probably means an uncompressed kernel overflows the size of the first memory bank, so there's probably no hope for modern kernels to boot on the machine. 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 minimalist userspace. So, it's probably time to say goodbyte to the kernel support for these platforms. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[PATCH v6 3/6] m68k: coldfire: Add clk_get_optional() function
clk_get_optional() returns NULL if not found instead of -ENOENT,
otherwise the behaviour is the same as clk_get().
Signed-off-by: Phil Edworthy
---
arch/m68k/coldfire/clk.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/m68k/coldfire/clk.c b/arch/m68k/coldfire/clk.c
index 7bc666e482eb..b221cabc7f54 100644
--- a/arch/m68k/coldfire/clk.c
+++ b/arch/m68k/coldfire/clk.c
@@ -87,6 +87,17 @@ struct clk *clk_get(struct device *dev, const char *id)
}
EXPORT_SYMBOL(clk_get);
+struct clk *clk_get_optional(struct device *dev, const char *id)
+{
+ struct clk *clk = clk_get(dev, id);
+
+ if (clk == ERR_PTR(-ENOENT))
+ clk = NULL;
+
+ return clk;
+}
+EXPORT_SYMBOL(clk_get_optional);
+
int clk_enable(struct clk *clk)
{
unsigned long flags;
--
2.17.1
[PATCH v6 0/6] clk: Add functions to get optional clocks
Quite a few drivers get an optional clock, e.g. a bus clock required to access peripheral's registers that is always enabled on some devices. This series adds of_clk_get_by_name_optional(), clk_get_optional() and devm_clk_get_optional() functions for this purpose. The functions behave the same as of_clk_get_by_name(), clk_get() and devm_clk_get() except that they will return NULL instead of -ENOENT. This allows for simpler error handling in the callers. *Note* This changes the return values for of_clk_get_by_name() in some cases, see [PATCH 1/6] clk: Add of_clk_get_by_name_optional() function. v6: - Rework the __of_clk_get_by_name() logic so as to avoid duplicate tests. - Add doxygen style comment for devm_clk_get_optional() args - Add clk_get_optional() to archs that don't use the commom clk framework. Phil Edworthy (6): clk: Add of_clk_get_by_name_optional() function clk: Add functions to get optional clocks m68k: coldfire: Add clk_get_optional() function MIPS: AR7: Add clk_get_optional() function MIPS: Loongson 2F: Add clk_get_optional() function arch/unicore32/kernel/clock.c: Add clk_get_optional() function arch/m68k/coldfire/clk.c | 11 arch/mips/ar7/clock.c | 11 arch/mips/loongson64/lemote-2f/clock.c | 11 arch/unicore32/kernel/clock.c | 11 drivers/clk/clk-devres.c | 18 - drivers/clk/clkdev.c | 91 ++ include/linux/clk.h| 38 +++ 7 files changed, 175 insertions(+), 16 deletions(-) -- 2.17.1
Re: m68k using deprecated internal APIs?
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 "heartbeat" trigger as is > > custom these days. > > > > That should clean out another chunk of legacy time-related code. > > > > Are you referring to LED heartbeat code in arch/m68k/kernel/time.c? > > > I suppose you are currently keeping the call to timer_interrupt() for > > exactly this reason (i.e. keep the heartbeat LED blinking)? > > It would be great to have that call inlined, which the compiler can't do > at the moment, because timer_interrupt() is in a different compilation > unit (arch/m68k/kernel/time.c). > > Is there some other benefit to eliminating the call to timer_interrupt() > that I've overlooked? 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 for it and instantiate using a driver in drivers/leds/*, and the function to provide the heartbeat be replaced with the existing heartbeat trigger in drivers/leds/trigger/ledtrig-heartbeat.c assigned as default trigger for that LED. I think that is WAY out of the focus for your current work (which, by the way, is a piece of art) but more something for the m68k maintainers to look into. Yours, Linus Walleij
