On Tue, Oct 21, 2014 at 1:52 PM, Grant Likely wrote:
> On Sat, Oct 18, 2014 at 9:11 AM, Bird, Tim wrote:
>> The answer is pretty easy, I think. I tried to mainline it once but failed,
>> and didn't really try again. If it is being found useful, we should try to
>>
On Sat, Oct 18, 2014 at 9:11 AM, Bird, Tim wrote:
> The answer is pretty easy, I think. I tried to mainline it once but failed,
> and didn't really try again. If it is being found useful, we should try to
> mainline it again, this time with more persistence. The reason it got
> rejected bef
gt; + *
> + * @dev: device model reference
> + * @ops: operations supported by the PWM device
> + * @label: requestor of the PWM device, or NULL
> + * @flags: PWM device state, see FLAG_*
> + * @tick_hz: base tick rate of PWM device, in HZ
> + * @polarity: active high (1), or active low (0)
&
On Mon, Feb 28, 2011 at 12:48 AM, Grant Likely
wrote:
> On Sun, Feb 27, 2011 at 06:11:43PM +, Tony Ibbs wrote:
>> KBUS is a lightweight, Linux kernel mediated, message system,
>> particularly intended for use in embedded environments.
>>
>> It is meant to be simpl
On Sun, Feb 27, 2011 at 06:11:43PM +, Tony Ibbs wrote:
> KBUS is a lightweight, Linux kernel mediated, message system,
> particularly intended for use in embedded environments.
>
> It is meant to be simple to use and understand. It is designed to
> provide predictable message delivery, determi
On Thu, Feb 3, 2011 at 10:04 AM, Tony Ibbs wrote:
> Apologies again for getting Grant's email address wrong on my initial
> email.
>
> On Tue, 1 Feb 2011 20:40:08 -0700
> Grant Likely wrote:
>
>> There are already a large number of communication channels available
&
> Tibs
>
> Begin forwarded message:
>
> Date: Fri, 28 Jan 2011 17:50:40 +
> From: Tony Ibbs
> To: Linux-embedded
> Cc: Grant Likely , Tibs at home
> , Richard Watts
> Subject: [RFC][PATCH] KBUS messaging subsystem
>
>
[...]
> We've got a
thinking.
http://wiki.linuxplumbersconf.org/2010:embedded_topics
Cheers,
g.
On Fri, Oct 15, 2010 at 9:50 PM, Grant Likely wrote:
> On Fri, Oct 15, 2010 at 09:20:28AM -0700, Kevin Hilman wrote:
>> Hi Grant,
>>
>> Do you have a draft agenda yet for the microconf? Specifically, I'd
>&
On Wed, Oct 20, 2010 at 01:13:34PM -0500, Bill Gatliff wrote:
> Grant:
>
> > I'm not hugely keen on the naming approach, and I'd rather see the
> > pwm core be responsible for the namespace.
>
> The problem with that, as I see it, is that then the channel
> identifiers become dependent on the ord
On Fri, Oct 01, 2010 at 10:17:47AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
Ditto on description.
> ---
> drivers/Kconfig |2 ++
> drivers/Makefile |2 ++
> drivers/leds/Kconfig | 22 --
> drivers/leds/Makefile |2 ++
> drivers/pwm/K
On Fri, Oct 01, 2010 at 10:17:45AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
Ditto on comment and patch title
> ---
> drivers/leds/Kconfig| 19 +++-
> drivers/leds/leds-pwm.c | 224 +++---
> include/linux/pwm/pwm-led.h | 33 +++
On Fri, Oct 01, 2010 at 10:17:46AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
Ditto on description
Otherwise pretty straight forward. Looks okay to me.
g.
> ---
> drivers/leds/ledtrig-dim.c | 96
>
> 1 files changed, 96 insertions
On Fri, Oct 01, 2010 at 10:17:44AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
This patch needs a better description about what is going on here. If
you're replacing an old driver, you must talk about what is changing
and why. You cannot assume that a future reader will have the co
On Fri, Oct 01, 2010 at 10:17:42AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
Hi Bill, comments below.
> ---
> Documentation/pwm.txt | 260 +++
> drivers/pwm/pwm.c | 635
> +++
> include/linux/pwm.h | 31
On Fri, Oct 01, 2010 at 10:17:43AM -0500, Bill Gatliff wrote:
> Signed-off-by: Bill Gatliff
> ---
Code looks pretty clean. Minor comments below, plus a rehash of an
old argument.
> drivers/pwm/gpio.c | 298
>
> 1 files changed, 298 inserti
On Wed, Oct 6, 2010 at 12:48 PM, Bill Gatliff wrote:
> Hector:
>
> On Sat, Oct 2, 2010 at 7:25 AM, Hector Oron wrote:
>> Hello Bill,
>>
>> Thanks for trying (again) to get this in mainline.
>> Are you planning to request a slot in the GIT at kernel.org to hold
>> and maintain this nice framework?
On Fri, Oct 15, 2010 at 09:20:28AM -0700, Kevin Hilman wrote:
> Hi Grant,
>
> Do you have a draft agenda yet for the microconf? Specifically, I'd
> like to get a better feel for how much time we'll dedicate to each
> topic, and therefore be better prepared for the discussions.
Working on it. Re
On Mon, Sep 20, 2010 at 10:14:43AM -0700, Kevin Hilman wrote:
> Grant Likely writes:
> > Here is my draft list:
> >
> > Kevin: How HWMOD is used to describe interconnections between internal
> > SoC devices.
>
> For omap_hwmod, I would like Paul Walmsley (Cc&#x
te up a draft of the actual agenda
and your proposals can be massaged appropriately to reflect exactly
what issues will be discussed.
Thoughts?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
f course, be dependent on the
> details of the implementation.
>
> The best thing to get started, IMHO, would be to identify
> a few drivers which have long probe times, and see
> how they could reduce these with the proposed boot cache.
> If you find that each new device adds some new wr
Update: We've now released the official call for proposals:
http://www.linuxplumbersconf.org/2010
Cheers,
g.
On Tue, Jul 6, 2010 at 1:56 PM, Grant Likely wrote:
>
> Hi all,
>
> I'm on the Linux Plumbers [1] planning committee this year, and I'm
> also head
010BOFS/proposals
If you have any questions, feel free to email me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Apr 10, 2010 at 5:39 PM, Paul Mundt wrote:
> In cases where you can specifically note that dependencies, doing so will
> save you a world of pain. Despite that, it's simply not possible to do
> this as a free-for-all. Devices or busses that can tolerate multi-threaded
> probing need to be
On Fri, Apr 9, 2010 at 1:23 PM, Bill Gatliff wrote:
> Guys:
>
>
> My recent post, "Requesting a GPIO that hasn't been registered yet", and
> Anton's reply thereto (thanks, Anton!) on linuxppc-dev got me thinking
> about the problem of dependencies between devices in different classes,
> and/or be
PowerPC, Microblaze and x86,
and it will most likely show up on ARM in the near future.
The most likely deviation is byte lane ordering either being big or
little endian, hence the driver using both io{read,write}32() and
io{read,write}32be(), but the 'be' variants aren't implement
evtmpfs is probably your best bet as that is what it is designed for.
You can also run a trivial script at boot to read /proc/devices and
create the device nodes as described in chapter 3, page 47 of LDD3:
http://lwn.net/images/pdf/LDD3/ch03.pdf
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Tech
On Mon, Nov 23, 2009 at 8:29 AM, Mark Brown
wrote:
> On Fri, Nov 20, 2009 at 03:21:31PM -0700, Grant Likely wrote:
>> On Tue, Nov 17, 2009 at 1:27 AM, David Brownell wrote:
>
>> > Since *everything* boils down to one or more signal lines,
>> > your argument lea
On Mon, Nov 23, 2009 at 7:13 AM, Bill Gatliff wrote:
> Grant Likely wrote:
>>
>> But that *isn't* the primary purpose of the GPIO subsystem. All that
>> stuff is layered on top of the GPIO pin management code and doesn't
>> really play into this debate.
&g
On Mon, Nov 23, 2009 at 7:12 AM, Bill Gatliff wrote:
> Grant Likely wrote:
>> I'm talking about discrete controllable entities.
>
> At the extreme, I see discrete, single-pin GPIO as being a degenerate
> case of PWM: only 0% or 100% duty cycle e.g. one-bit granularity, a
ue. That's part of why I object to wanting to combine
> it with GPIOs ... or, combine everything else with GPIOs
> too (like PWMs).
>
> But Grant talks about wanting such things, and if he can
> deliver it, more power to him.
Just to be clear, I'm *not* talking about pin
On Tue, Nov 17, 2009 at 8:39 AM, Bill Gatliff wrote:
> Grant Likely wrote:
>> Hi Bill
>>
>> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff wrote:
>>
>>> This series implements a Generic PWM Device API, including reference
>>> implementations for the
On Tue, Nov 17, 2009 at 1:27 AM, David Brownell wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>> I'm concerned about the approach taken here. As I understand it, the
>> PWM signals are very similar to GPIOs in that each PWM device controls
>> an external s
On Tue, Nov 17, 2009 at 12:47 AM, David Brownell wrote:
> On Friday 13 November 2009, Grant Likely wrote:
>> Right now, I don't
>> see a fundamental difference is between GPIO and PWM pin management.
>> It is essentially the same problem, and in many cas
On Fri, Nov 13, 2009 at 9:22 PM, Mike Frysinger wrote:
> On Fri, Nov 13, 2009 at 14:08, Grant Likely wrote:
>> On Wed, Oct 15, 2008 at 11:14 AM, Bill Gatliff wrote:
>>> This series implements a Generic PWM Device API, including reference
>>> implementations for th
also have a PWM.
What is the reason for bringing in an entirely new framework instead
of extending the GPIO API or gpiolib? I'm not too excited about
having two entirely different frameworks for what basically boils down
to "numbered signal pins".
g.
--
Grant Likely, B.Sc., P.E
f others have any better
> ideas.
Yup, that's good. Between Anton's, Wolfram's and your work things are
going the right way.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-
On Fri, Oct 9, 2009 at 8:01 AM, Nate Case wrote:
> On Thu, 2009-10-08 at 23:40 -0600, Grant Likely wrote:
>> For your future reference, patches that look at the device tree should
>> also cc: devicetree-disc...@lists.ozlabs.org so that new bindings can
>> be reviewed and c
On Thu, Oct 8, 2009 at 4:20 PM, Anton Vorontsov
wrote:
> On Thu, Oct 08, 2009 at 09:48:50AM -0600, Grant Likely wrote:
>> But the focus is still on creating pdata. If a translator gets too
>> big, then sure, split it into a separate file. Until then, there I
>> see no goo
is already in mainline, but can you please post the
device tree fragment that you're using to describe this chip? I want
to make sure we don't get stuck with things in the kernel that will be
hard to maintain in the long term.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologi
On Thu, Oct 8, 2009 at 9:10 AM, Anton Vorontsov
wrote:
> On Thu, Oct 08, 2009 at 08:53:46AM -0600, Grant Likely wrote:
> [...]
>> Please don't. It is such a small amount of code,
>
> It's *always* a small amound of code, at a start. Then we get
> floppy disk drive
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokier wrote:
> Grant Likely wrote:
>> On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier wrote:
>> > Something which lets you specify a dependency in a one-line
>> > MODULE_INIT_PREREQS() macro would be much nicer.
>>
>> Th
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokier wrote:
> Grant Likely wrote:
>> http://patchwork.ozlabs.org/patch/24152/
>>
>> I never actually pushed through and finished it because it turned out
>> to be a non-issue for Ethernet devices in the end. However, I can s
river can use a
bus_register_notifier() variant without caring about the device
registration order, and the drivers notifier callback will get called
at the appropriate time.
In your example case I could see the framebuffer driver deferring the
final part of its initialization until the needed i2c de
AMP or at least the idea of the kernel communicating with other OSes
> on the same SoC in multi-core systems is interesting.
Indeed, and not just for SoCs. I'm currently looking at Ira's
adaptation of virtio to use it for IPC between two separate CPUs
running separate Linux instances
i2c).
In short, the drawbacks are complexity on devices which cannot afford
the complexity.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 2, 2009 at 3:10 PM, Russell King wrote:
> On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote:
>> Embedded PowerPC and Microblaze has tackled this problem with the
>> "Flattened Device Tree" data format which is derived from the
>> OpenFirmwa
ngs like
> furthering the deployment of platform_device, clocksource/clockdevice, and
> so on.
No, not comprehensive; just common. It makes sense to spend the
effort on the patterns and devices which are common. It may not cover
everything, but it doesn't have to to be valuable.
g.
--
Grant
On Tue, Jun 2, 2009 at 11:48 AM, James Bottomley
wrote:
> On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote:
>> One topic that seems to garner debate is the issue of decoupling the
>> kernel image from the target platform. ie. On x86, PowerPC and Sparc
>> a kernel i
eeds out a lot of common mistakes.
I also think the stuff in Documentation/powerpc/dts-bindings needs to
be moved out to a common location.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the
r ppc, sparc, and microblaze could probably use
> some consolidation and getting some of the arch maintainers together in a room
> might prove fruitful. Particularly if we are going to discuss how to make
> drivers work for device tree and standard platforms alike.
>
> josh
>
ces will get registered first and the Ethernet driver
needs a mechanism to defer initialization until the PHY device is
ready.
> Of course, if you're using loadable modules, then the dependencies
> should take care of things for you.
For the bus infrastructure, yes, but not for the bus instances.
g
it be useful to have an alternate bus_register_notifier()
function which also generated ADD_DEVICE and BOUND_DRIVER
notifications for devices already present? If others see value in it
then I'll code something up.
Third, let me know if it seems like I'm looking at this problem in the
wrong way.
g.
http://www.openfirmware.org in more-readable formats like
> PDF)
>
> http://www.openbios.org/
>
>
> But here's the real question; why do you need an opensource implementation?
> Curiosity?
Umm, so that it can be ported to new boards perhaps? So that
developers can wor
.openfirmware.info/SmartFirmware
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
for OF which will be just wrapper for platform
> driver... Just like you suggested.
More complex than necessary. Just give the driver 2 blocks of binding
code; one for OF, one for non-OF. No need to split up the driver.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; index 000..6a8258d
> --- /dev/null
> +++ b/include/linux/mdio-gpio.h
> @@ -0,0 +1,30 @@
> +/*
> + * MDIO-GPIO bus platform data structures
> + *
> + * Copyright (C) 2008, Paulius Zaleckas <[EMAIL PROTECTED]>
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#ifndef __LINUX_MDIO_GPIO_H
> +#define __LINUX_MDIO_GPIO_H
> +
> +struct mdio_gpio_phy {
> + /* PHY address on MDIO bus */
> + unsigned int addr;
> + /* preconfigured irq connected to PHY */
> + int irq;
> +};
> +
> +struct mdio_gpio_platform_data {
> + /* GPIO numbers for bus pins */
> + unsigned int mdc;
> + unsigned int mdio;
> +
> + unsigned int nr_phys;
> + struct mdio_gpio_phy *phys;
> +};
> +
> +#endif /* __LINUX_MDIO_GPIO_H */
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
remove all OF specific code from this file and add another one
> creating the struct mdio_gpio_platform_data using OF specific functions?
This is a very simple driver. There is no need to split it into two
files. Have two sections of bus binding (OF and non-OF) is just fine.
g.
--
Gr
mdio_gpio_platform_data *pdata;
> + struct device *dev = &pdev->dev;
> +#endif
Instead of doing multiple #ifdef sections throughout the probe
function, use one #ifdef block for the OF stuff and another for all
the non-OF stuff. You can factor out any non-trivial common code
blocks into shared helper functions.
Otherwise, looking good.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Oct 31, 2008 at 10:49 AM, Paulius Zaleckas
<[EMAIL PROTECTED]> wrote:
> Signed-off-by: Paulius Zaleckas <[EMAIL PROTECTED]>
> Cc: Laurent Pinchart <[EMAIL PROTECTED]>
> Cc: Grant Likely <[EMAIL PROTECTED]>
> Cc: Mike Frysinger <[EMAIL PROTECTED]>
test this driver under OF.
>
> Signed-off-by: Paulius Zaleckas <[EMAIL PROTECTED]>
> Cc: Laurent Pinchart <[EMAIL PROTECTED]>
> Cc: Grant Likely <[EMAIL PROTECTED]>
> Cc: Mike Frysinger <[EMAIL PROTECTED]>
> ---
>
> drivers/net/phy/
On Wed, Oct 29, 2008 at 2:44 AM, Paulius Zaleckas
<[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>> On Tue, Oct 28, 2008 at 5:31 AM, Paulius Zaleckas
>> <[EMAIL PROTECTED]> wrote:
>>> Mike Frysinger wrote:
>>>> On Tue, Oct 28, 2008 at 06:35,
On Tue, Oct 28, 2008 at 9:17 AM, Russell King - ARM Linux
<[EMAIL PROTECTED]> wrote:
> On Tue, Oct 28, 2008 at 07:08:06AM -0600, Grant Likely wrote:
>> On Tue, Oct 28, 2008 at 1:46 AM, Paulius Zaleckas
>> <[EMAIL PROTECTED]> wrote:
>> > Grant Likely wrote:
>
a minute This is the same driver and it's just been
duplicated. NAK. Please don't do this. Instead add a platform bus
binding to the existing driver. Most of the code can be shared.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from th
On Tue, Oct 28, 2008 at 1:46 AM, Paulius Zaleckas
<[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>> The IRQ array is fixed size. You can add it to the mdio_gpio_info
>> structure and then just set the pointer here so that only one kzalloc
>> is needed.
>
> It
On Mon, Oct 27, 2008 at 12:53:22PM +0200, Paulius Zaleckas wrote:
> Useful for machines where PHY control is connected to GPIO.
> This driver also supports interrupts from PHY.
>
> Changes since v1:
> - fixed releasing of gpio (thanks to Sascha Hauer)
> - fixed compiling due to bus->dev to bus->pa
On Sat, Oct 18, 2008 at 07:05:28PM +0200, Roberto A. Foglietta wrote:
> Hi,
>
> I would know if somebody have ever tried to run linux on this piece of hw
>
> http://www.mio-tech.be/en/gps-navigation-device-Mio-P350-specifications.htm
>
> do you think it is possible? Do you know somebody who ha
On Mon, Sep 22, 2008 at 4:11 PM, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 22, 2008 at 18:08, Grant Likely <[EMAIL PROTECTED]> wrote:
>> Jeremy,
>>
>> Can we eliminate the linuxppc-embedded mailing list and merge it with
>> linuxppc-dev? I
Jeremy,
Can we eliminate the linuxppc-embedded mailing list and merge it with
linuxppc-dev? I don't think we need two separate lists anymore and
patches to linuxppc-embedded don't always get dealt with.
Anyone have any objections to eliminating linuxppc-embedded?
g.
--
Grant Li
On Wed, Sep 17, 2008 at 08:23:33PM +0200, Robert Schwebel wrote:
> On Wed, Sep 17, 2008 at 11:13:23AM -0700, Grant Likely wrote:
> > BTW, I was talking with a guy from TI last night (Mike Turquette; works
> > on the OMAP) and I asked him my standard question about what he think
Hey Behan,
BTW, I was talking with a guy from TI last night (Mike Turquette; works
on the OMAP) and I asked him my standard question about what he thinks
about the state of building root filesystems for embedded systems.
When he listed the toolkits he knows about and is interested in, ELBS
was ei
On Mon, Aug 18, 2008 at 5:30 AM, Geert Uytterhoeven
<[EMAIL PROTECTED]> wrote:
> On Thu, 14 Aug 2008, Behan Webster wrote:
>> Grant Likely wrote:
>> > On Fri, Aug 8, 2008 at 11:03 AM, Behan Webster <[EMAIL PROTECTED]> wrote:
>> > Also, when booting on someth
On Thu, Aug 14, 2008 at 1:20 PM, Behan Webster <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>> On Thu, Aug 14, 2008 at 8:35 AM, Behan Webster <[EMAIL PROTECTED]> wrote:
>>
>>> Grant Likely wrote:
>>>
>>>> Also, when booting on some
On Thu, Aug 14, 2008 at 8:35 AM, Behan Webster <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>> Also, when booting on something like a 5200 with an uncommon serial
>> ports name (ttyPSC0), I had to manually add the /dev/ttyPSC0 device
>> file before it would boot.
ed device trees. It is a 2.6 thing
for arch/powerpc.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
, when booting on something like a 5200 with an uncommon serial
ports name (ttyPSC0), I had to manually add the /dev/ttyPSC0 device
file before it would boot.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Aug 12, 2008 at 06:30:54PM -0700, David VomLehn wrote:
> Grant Likely wrote:
>
>> I'm not thrilled with this patch. It seems so much more straight
>> forward in your special case, but it comes at the expense of making
>> the code path more complex in every o
d with this patch. It seems so much more straight
forward in your special case, but it comes at the expense of making
the code path more complex in every other case.
I would much rather see this be done using the existing console driver
interface. The only possible reason I could see wanting to do thi
On Tue, Aug 5, 2008 at 11:28 AM, Mihaela Grigore
<[EMAIL PROTECTED]> wrote:
> If I intend to run a 2.6 linux kernel under a powerpc emulator, what
> is needed to make a minimal bootable system? I mean, apart from the
> kernel itself and busybox, do I need a bootloader ? If no actual
> hardware is u
On Tue, Jul 29, 2008 at 10:18:37PM -0400, Behan Webster wrote:
> A quick announcement of the release of elbs, or the "Embedded Linux
> Build System" (it seemed like a good name at the time I started writing
> it...) So far it's just a few utilities that I wrote to make a few of
> my own projects e
>> a blunt instrument.
>
> Yes, it's a blunt instrument, but blunt instruments are often effective.
>
> I disagree with your claim that using it as a test isn't a good idea.
> I would, however, grant you that using it as your _only_ test is a bad
> idea :)
80 matches
Mail list logo
