On 05/27/2016 08:36 PM, Mark Brown wrote:
Personally the way I parse this situation is that the kernel is taking
a look at what's in the DT and making an effort to present it usefully
in the running systems. Fixing our current interpretation in stone as
a supported thing when we don't have to
On 05/27/2016 08:36 PM, Mark Brown wrote:
Personally the way I parse this situation is that the kernel is taking
a look at what's in the DT and making an effort to present it usefully
in the running systems. Fixing our current interpretation in stone as
a supported thing when we don't have to
On 05/26/2016 08:47 PM, Mark Brown wrote:
> On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote:
>
>> One of the main drivers behind devicetree was that Linus got fed
>> up with the churn for all platform device changes in arch/arm.
>> I faintly recall h
On 05/26/2016 08:47 PM, Mark Brown wrote:
> On Thu, May 26, 2016 at 12:58:22PM +0200, Christer Weinigel wrote:
>
>> One of the main drivers behind devicetree was that Linus got fed
>> up with the churn for all platform device changes in arch/arm.
>> I faintly recall h
On 05/26/2016 12:07 PM, Mark Brown wrote:
> I think Rob's referring to the fact that there are no in tree DTs
> that use this feature - all the aliases for SPI controllers in
> mainline are string based.
One of the main drivers behind devicetree was that Linus got fed up
with the churn for all
On 05/26/2016 12:07 PM, Mark Brown wrote:
> I think Rob's referring to the fact that there are no in tree DTs
> that use this feature - all the aliases for SPI controllers in
> mainline are string based.
One of the main drivers behind devicetree was that Linus got fed up
with the churn for all
On 05/26/2016 03:44 AM, Rob Herring wrote:
Lovely. "Here's something that's simple and useful for users. Let's
break it". What part of "we do not break userspace" do you not
understand? Because that would be a user visible change.
The other saying is "if it is not upstream, it doesn't exist."
On 05/26/2016 03:44 AM, Rob Herring wrote:
Lovely. "Here's something that's simple and useful for users. Let's
break it". What part of "we do not break userspace" do you not
understand? Because that would be a user visible change.
The other saying is "if it is not upstream, it doesn't exist."
On 05/25/2016 08:44 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote:
>> On 5/25/2016 10:49 AM, Rob Herring wrote:
>
>>> Things get undocumented all the time when we deprecate them.
>
>> If it is deprecated then it should be documented as deprecated
>> so
On 05/25/2016 08:44 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 11:06:46AM -0700, Frank Rowand wrote:
>> On 5/25/2016 10:49 AM, Rob Herring wrote:
>
>>> Things get undocumented all the time when we deprecate them.
>
>> If it is deprecated then it should be documented as deprecated
>> so
On 05/25/2016 12:38 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 10:20:34AM +0100, Mark Rutland wrote:
>> On Tue, May 24, 2016 at 01:41:26PM -0700, Frank Rowand wrote:
>
>>> The code and behavior is in the Linux kernel. It should be
>>> visible in the documentation instead of being a big
On 05/25/2016 12:38 PM, Mark Brown wrote:
> On Wed, May 25, 2016 at 10:20:34AM +0100, Mark Rutland wrote:
>> On Tue, May 24, 2016 at 01:41:26PM -0700, Frank Rowand wrote:
>
>>> The code and behavior is in the Linux kernel. It should be
>>> visible in the documentation instead of being a big
On 05/24/2016 08:32 PM, Mark Brown wrote:
> On Tue, May 24, 2016 at 08:03:48PM +0200, Christer Weinigel wrote:
>> On 05/24/2016 07:20 PM, Mark Brown wrote:
>
>>> I'm not sure this is something we want to support at all, I
>>> can't immediately see anythi
On 05/24/2016 08:32 PM, Mark Brown wrote:
> On Tue, May 24, 2016 at 08:03:48PM +0200, Christer Weinigel wrote:
>> On 05/24/2016 07:20 PM, Mark Brown wrote:
>
>>> I'm not sure this is something we want to support at all, I
>>> can't immediately see anythi
On 05/24/2016 07:20 PM, Mark Brown wrote:
>> Not having used devicetree that much it was surprisingly hard to
>> figure out how to assign a stable bus number to a spi bus. Add
>> a simple example that shows how to do that.
>
> I'm not sure this is something we want to support at all, I can't
On 05/24/2016 07:20 PM, Mark Brown wrote:
>> Not having used devicetree that much it was surprisingly hard to
>> figure out how to assign a stable bus number to a spi bus. Add
>> a simple example that shows how to do that.
>
> I'm not sure this is something we want to support at all, I can't
Document how to use devicetree aliases to assign a stable
bus number to a spi bus.
Signed-off-by: Christer Weinigel <chris...@weinigel.se>
---
Trivial documentation change.
Not having used devicetree that much it was surprisingly hard to
figure out how to assign a stable bus number to
Document how to use devicetree aliases to assign a stable
bus number to a spi bus.
Signed-off-by: Christer Weinigel
---
Trivial documentation change.
Not having used devicetree that much it was surprisingly hard to
figure out how to assign a stable bus number to a spi bus. Add a
simple
On 2014-05-07 15:35, One Thousand Gnomes wrote:
> IoT devices don't care. Most embedded devices don't care. A lot of the
> current generation of proprietary non Linux very low end RTOS systems
> support *one socket*, some even use a wireless controller which has a
> proprietary mini tcp/ip and
On 2014-05-07 15:35, One Thousand Gnomes wrote:
IoT devices don't care. Most embedded devices don't care. A lot of the
current generation of proprietary non Linux very low end RTOS systems
support *one socket*, some even use a wireless controller which has a
proprietary mini tcp/ip and wifi
Andi Kleen wrote:
RFC: Update coding standard to avoid split up printk format strings
While we're talking about checkpatch.pl, I'd definitely like to teach
checkpatch about "list_for_each" and friends.
list_for_each is flow control, not a function call. I find it much
easier to see that
Andi Kleen wrote:
RFC: Update coding standard to avoid split up printk format strings
While we're talking about checkpatch.pl, I'd definitely like to teach
checkpatch about list_for_each and friends.
list_for_each is flow control, not a function call. I find it much
easier to see that
On Sat, 9 Feb 2008 17:41:00 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> On Feb 9, 2008 5:13 PM, Christer Weinigel <[EMAIL PROTECTED]>
> wrote:
> > But lets say that the b-tree code uses Linux-only primitives such as
> > kmalloc or spinlocks
On Thu, 7 Feb 2008 18:49:39 +0100
Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:
> > It requires software that is *distributed* as part of a GPL
> > work to itself be GPL. At time of distribution, a kernel module is
> > neither using nor linked to the kernel.
>
> Oh, come on! You cannot turn a
On Sat, 09 Feb 2008 05:10:04 +1030
David Newall <[EMAIL PROTECTED]> wrote:
> Now, Alexander Terekhov has forwarded some links to me, relating to
> the question of whether or not a Linux kernel module can be original.
> Bear in mind that these links relate to U.S. Copyright Law.
Mercy, no, with
On Sat, 09 Feb 2008 05:10:04 +1030
David Newall [EMAIL PROTECTED] wrote:
Now, Alexander Terekhov has forwarded some links to me, relating to
the question of whether or not a Linux kernel module can be original.
Bear in mind that these links relate to U.S. Copyright Law.
Mercy, no, with
On Thu, 7 Feb 2008 18:49:39 +0100
Hans-Jürgen Koch [EMAIL PROTECTED] wrote:
It requires software that is *distributed* as part of a GPL
work to itself be GPL. At time of distribution, a kernel module is
neither using nor linked to the kernel.
Oh, come on! You cannot turn a derived work
On Sat, 9 Feb 2008 17:41:00 +0200
Pekka Enberg [EMAIL PROTECTED] wrote:
On Feb 9, 2008 5:13 PM, Christer Weinigel [EMAIL PROTECTED]
wrote:
But lets say that the b-tree code uses Linux-only primitives such as
kmalloc or spinlocks, and that I wrote the code specifically for the
Linux kernel
On Wed, 06 Feb 2008 21:55:45 +0100
Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> > So how does that invalidate my point? Intel did jump through a lot
> > of hoops to avoid giving away the code that controls their radio.
> > When the regulatory daemon stuff got too much complaints, they
> >
On Tue, 5 Feb 2008 13:46:08 +0200
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi David,
>
> Marcel Holtmann writes:
> > > You driver was meant to be running as Linux kernel module and
> > > thus it is derivative work.
>
> On Feb 5, 2008 1:39 PM, David Newall <[EMAIL PROTECTED]> wrote:
> > It is
On Wed, 6 Feb 2008 12:28:10 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
> > On Tue, 5 Feb 2008 12:34:18 -0800
> > Greg KH <[EMAIL PROTECTED]> wrote:
> >
> > > In the end, i
On Mon, 04 Feb 2008 22:38:11 +0100
Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Christer,
>
> while the HAL case of Atheros might be still true despite the fact
> that an OpenHAL has been around for a long time now. The Intel
> argument is out of the picture since quite some time. The
On Tue, 5 Feb 2008 12:34:18 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> In the end, it's up to the copyright holders to enforce the license.
> And as I have stated in the past, a number of them have made public
> statements as to what they think about this issue. And it corresponds
> exactly with
On Mon, 04 Feb 2008 22:38:11 +0100
Marcel Holtmann [EMAIL PROTECTED] wrote:
Hi Christer,
while the HAL case of Atheros might be still true despite the fact
that an OpenHAL has been around for a long time now. The Intel
argument is out of the picture since quite some time. The regulatory
On Wed, 6 Feb 2008 12:28:10 -0800
Greg KH [EMAIL PROTECTED] wrote:
On Wed, Feb 06, 2008 at 09:14:48PM +0100, Christer Weinigel wrote:
On Tue, 5 Feb 2008 12:34:18 -0800
Greg KH [EMAIL PROTECTED] wrote:
In the end, it's up to the copyright holders to enforce the
license. And as I have
On Tue, 5 Feb 2008 13:46:08 +0200
Pekka Enberg [EMAIL PROTECTED] wrote:
Hi David,
Marcel Holtmann writes:
You driver was meant to be running as Linux kernel module and
thus it is derivative work.
On Feb 5, 2008 1:39 PM, David Newall [EMAIL PROTECTED] wrote:
It is precisely the fact
On Wed, 06 Feb 2008 21:55:45 +0100
Marcel Holtmann [EMAIL PROTECTED] wrote:
So how does that invalidate my point? Intel did jump through a lot
of hoops to avoid giving away the code that controls their radio.
When the regulatory daemon stuff got too much complaints, they
finally redid
Diego Zuccato wrote:
In the cited example it's illegal to go outside certain parameters
SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't
allow it and the sw could do nothing... not considering hw mods).
Another example is WiFi: USA, Europe and Japan allows a different number
Diego Zuccato wrote:
In the cited example it's illegal to go outside certain parameters
SOMEWHERE (if it was illegal everywhere, the the hardware shouldn't
allow it and the sw could do nothing... not considering hw mods).
Another example is WiFi: USA, Europe and Japan allows a different number
Pekka Enberg wrote:
Why are we discussing this again? The Linux kernel is distributed
under the GPLv2 and even though there are some legal gray areas
regarding derived work (think nvidia and ati binary blobs here), the
license is not friendly towards proprietary drivers at all.
Why? Because
On Sat, 2 Feb 2008 11:19:30 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
>I do know that the current usbfs interface is a major pain, hence the
>work to create usbfs2. I know those developers could use the help in
>getting that cleaned up and into the kernel tree.
>Also see the rapid development
On Sat, 2 Feb 2008 11:19:30 -0800
Greg KH [EMAIL PROTECTED] wrote:
I do know that the current usbfs interface is a major pain, hence the
work to create usbfs2. I know those developers could use the help in
getting that cleaned up and into the kernel tree.
Also see the rapid development these
Pekka Enberg wrote:
Why are we discussing this again? The Linux kernel is distributed
under the GPLv2 and even though there are some legal gray areas
regarding derived work (think nvidia and ati binary blobs here), the
license is not friendly towards proprietary drivers at all.
Why? Because
On Fri, 25 Jan 2008 10:02:32 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> FYI, this is a patch that will be sent out in the next round to Linus
> for inclusion in 2.6.25.
>
> If anyone has any objections about it, please let me know.
Yes, I have objections and I've told you before.
> Over two
On Fri, 25 Jan 2008 10:02:32 -0800
Greg KH [EMAIL PROTECTED] wrote:
FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.
If anyone has any objections about it, please let me know.
Yes, I have objections and I've told you before.
Over two years
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
> > On 2008-01-14, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
> > > Yes, that is a usual bug/problem in common distributions[0] as
> > > there is no real
On Mon, 14 Jan 2008 10:57:09 +0100
Bernd Petrovitsch [EMAIL PROTECTED] wrote:
On Mon, 2008-01-14 at 09:48 +, Tuomo Valkonen wrote:
On 2008-01-14, Bernd Petrovitsch [EMAIL PROTECTED] wrote:
Yes, that is a usual bug/problem in common distributions[0] as
there is no real guarantee that
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> >
> > I'm speaking specifically in terms of 64-bit platforms here.
> > Shouldn't we unconditionally drop outb_p doing extra port I/O on
> > 64-bit architectures? Especially considering they
On Wed, 09 Jan 2008 10:18:11 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially considering they don't even
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> > Alan Cox wrote:
> > > The natsemi docs here say otherwise. I trust them not you.
> > >
> > As well you should. I am honestly curious (for my own
On Tue, 08 Jan 2008 15:28:03 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Register compatible. Not the same chips or even the same masks or
> timing requirements.
No, but somehow people keep making similar mistakes. The DEC HiNote
needed outb_p to function correctly? That was
On Tue, 08 Jan 2008 13:44:54 -0500
"David P. Reed" <[EMAIL PROTECTED]> wrote:
> Ondrej Zary wrote:
> > On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
> >
> >> Windows these days does delays with timing loops or the
> >> scheduler. It doesn't use a "port". Also, Windows XP only
> >>
On Tue, 08 Jan 2008 13:44:54 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Ondrej Zary wrote:
On Tuesday 08 January 2008 18:24:02 David P. Reed wrote:
Windows these days does delays with timing loops or the
scheduler. It doesn't use a port. Also, Windows XP only
supports machines
On Tue, 08 Jan 2008 15:28:03 -0500
David P. Reed [EMAIL PROTECTED] wrote:
Register compatible. Not the same chips or even the same masks or
timing requirements.
No, but somehow people keep making similar mistakes. The DEC HiNote
needed outb_p to function correctly? That was definitely a
On Tue, 08 Jan 2008 18:52:42 -0800
Zachary Amsden [EMAIL PROTECTED] wrote:
On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
Alan Cox wrote:
The natsemi docs here say otherwise. I trust them not you.
As well you should. I am honestly curious (for my own satisfaction)
as to
On Mon, 07 Jan 2008 20:38:09 +0100
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> Christer Weinigel <[EMAIL PROTECTED]> wrote:
>
> > How do you find out the speed of the ISA bus? AFAIK there is no
> > standardized way to do that. On the Geode SC2200 the ISA bus spee
On Mon, 07 Jan 2008 20:38:09 +0100
Bodo Eggert [EMAIL PROTECTED] wrote:
Christer Weinigel [EMAIL PROTECTED] wrote:
How do you find out the speed of the ISA bus? AFAIK there is no
standardized way to do that. On the Geode SC2200 the ISA bus speed
is usually the PCI clock divided by 4
On Thu, 03 Jan 2008 17:17:29 +0200
Benny Halevy <[EMAIL PROTECTED]> wrote:
> On Jan. 03, 2008, 14:30 +0200, Arnaldo Carvalho de Melo
> > Agreed, CodingStyle is not about mindless consistency such as "for
> > (" is the right thing, so "list_for_each (" is consistent with it,
> > it is about
On Thu, 03 Jan 2008 13:34:45 +0100
Tomas Carnecky <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> > By the way, what is the consensus on lines over 80 characters?
> > checkpatch complains about the following:
> >
> > WARNING: line over 80 chara
On Thu, 03 Jan 2008 13:34:45 +0100
Tomas Carnecky [EMAIL PROTECTED] wrote:
Christer Weinigel wrote:
By the way, what is the consensus on lines over 80 characters?
checkpatch complains about the following:
WARNING: line over 80 characters
#762: FILE: drivers/spi/spi_s3c24xx_dma.c:720
On Wed, 02 Jan 2008 00:11:54 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> Well, on the PIIX it is and I guess on anything where it's _not_
> fully internal an 0xf0 write wouldn't have any effect on IRQ13...
>
> When you earlier mentioned this it seemed 0xed switched on DMI would
> be good
On Tue, 1 Jan 2008 23:12:50 +
Alan Cox <[EMAIL PROTECTED]> wrote:
> > Besides the above there are only a handful of _p uses outside of
> > real ISA device drivers, and those should not be relevant for a
> > modern PC unless somebody wants to use an 8390 based PCMCIA card,
> > but we could
On Tue, 01 Jan 2008 13:21:47 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> >
> > out 80h, al is only two bytes. Any alternative that has been
> > suggested in this discussion will use more space. mov dx,
> > alt_port;
On Tue, 1 Jan 2008 22:01:43 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > out 80h, al is only two bytes. Any alternative that has been
> > suggested in this discussion will use more space. mov dx,
> > alt_port; out dx, al will be larger, a function call will
> > definitely be a lot larger.
On Tue, 01 Jan 2008 20:59:20 +0100
Rene Herman <[EMAIL PROTECTED]> wrote:
> On 01-01-08 20:35, Christer Weinigel wrote:
>
> > On old hardware (or anything with an ISA bus which I'd guess
> > includes the Geode SCx200 SoC which is basically a MediaGX
> > processor
On Tue, 1 Jan 2008 19:45:24 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > > there strong counter-arguments against doing the clean thing and
> > > adding an udelay(2) (or udelay(1)) to replace those _p() uses in
> > > ISA drivers?
> >
> > #1
On Tue, 1 Jan 2008 19:46:59 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Christer Weinigel <[EMAIL PROTECTED]> wrote:
>
> > What I'm afraid is that udelay will be significantly slower, [...]
>
> why should it be significantly slower?
out 80h, al is
On Tue, 1 Jan 2008 17:43:38 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> if someone runs a fresh new kernel on an ancient device then timings
> _will_ change a bit, no matter what we do. Alignments change, the
> compiler output will change (old compilers get deprecated so a new
> compiler
On Tue, 1 Jan 2008 17:43:38 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
if someone runs a fresh new kernel on an ancient device then timings
_will_ change a bit, no matter what we do. Alignments change, the
compiler output will change (old compilers get deprecated so a new
compiler might
On Tue, 1 Jan 2008 19:46:59 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Christer Weinigel [EMAIL PROTECTED] wrote:
What I'm afraid is that udelay will be significantly slower, [...]
why should it be significantly slower?
out 80h, al is only two bytes. Any alternative that has been
On Tue, 1 Jan 2008 19:45:24 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Alan Cox [EMAIL PROTECTED] wrote:
there strong counter-arguments against doing the clean thing and
adding an udelay(2) (or udelay(1)) to replace those _p() uses in
ISA drivers?
#1 udelay has to be for the
On Tue, 01 Jan 2008 20:59:20 +0100
Rene Herman [EMAIL PROTECTED] wrote:
On 01-01-08 20:35, Christer Weinigel wrote:
On old hardware (or anything with an ISA bus which I'd guess
includes the Geode SCx200 SoC which is basically a MediaGX
processor, a southbridge and an ISA bus with a Super
On Tue, 1 Jan 2008 22:01:43 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
out 80h, al is only two bytes. Any alternative that has been
suggested in this discussion will use more space. mov dx,
alt_port; out dx, al will be larger, a function call will
definitely be a lot larger. People
On Tue, 01 Jan 2008 13:21:47 -0800
H. Peter Anvin [EMAIL PROTECTED] wrote:
Christer Weinigel wrote:
out 80h, al is only two bytes. Any alternative that has been
suggested in this discussion will use more space. mov dx,
alt_port; out dx, al will be larger, a function call
On Tue, 1 Jan 2008 23:12:50 +
Alan Cox [EMAIL PROTECTED] wrote:
Besides the above there are only a handful of _p uses outside of
real ISA device drivers, and those should not be relevant for a
modern PC unless somebody wants to use an 8390 based PCMCIA card,
but we could tell them
On Wed, 02 Jan 2008 00:11:54 +0100
Rene Herman [EMAIL PROTECTED] wrote:
Well, on the PIIX it is and I guess on anything where it's _not_
fully internal an 0xf0 write wouldn't have any effect on IRQ13...
When you earlier mentioned this it seemed 0xed switched on DMI would
be good enough, but
sed system) there is at least one fairly modern CPU, which is used in
lots of embedded systems, and in active use, which does need the _p.
Just a data point... It's not only ancient systems that need _p.
/Christer
--
"Just how much can I get away with and still go to heaven?&
of embedded systems, and in active use, which does need the _p.
Just a data point... It's not only ancient systems that need _p.
/Christer
--
Just how much can I get away with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
--
To unsubscribe from this list
Hi Andy,
you seem to be the last person messing around with checkpatch.pl so I'm
addressing this to you. :-)
checkpatch complains about the following:
WARNING: no space between function name and open parenthesis '('
#520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
+ list_for_each_entry
Hi Andy,
you seem to be the last person messing around with checkpatch.pl so I'm
addressing this to you. :-)
checkpatch complains about the following:
WARNING: no space between function name and open parenthesis '('
#520: FILE: drivers/spi/spi_s3c24xx_dma.c:478:
+ list_for_each_entry
a rather big change which might break userspace. And yes,
there are applications that rely on this, I've used it when building
software for cross compiling.
/Christer
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall <[EMAIL PROTECTED]> wrote:
> Christer Weinigel wrote:
> > *spend
it when building
software for cross compiling.
/Christer
On Thu, 27 Sep 2007 06:49:28 +0930
David Newall [EMAIL PROTECTED] wrote:
Christer Weinigel wrote:
*spends five minutes with Google*
From the OpenBSD FAQ (an operating system most know for being
really, really focused on security
nvinced?
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mo
with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
r the next five years? Or
will he drop support for Reiser4 the same way he dropped support for
the old Reiser3 when Reiser4 came along? Or will he drop Reiser4 when
the grant to do Reiser 4 development expires?
/Christer
--
"Just how much can I get away with and still go to heaven?"
Chri
drop support for Reiser4 the same way he dropped support for
the old Reiser3 when Reiser4 came along? Or will he drop Reiser4 when
the grant to do Reiser 4 development expires?
/Christer
--
Just how much can I get away with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http
hardware choice is cost, cost and cost.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[EMAIL PROTECTED]> http://www.weinigel.se
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
it would probably cost them very little to do that.
If I could find a good (4800-9600 dpi) scanner which said "supported
by SANE" on the box I'd buy it immedately.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[EMAIL PROTECT
very little to do that.
If I could find a good (4800-9600 dpi) scanner which said supported
by SANE on the box I'd buy it immedately.
/Christer
--
Just how much can I get away with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
-
To unsubscribe from
choice is cost, cost and cost.
/Christer
--
Just how much can I get away with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
rt alla applications.
And yes, this have been very useful for me in real life. So it's
really nice to have both suspend-to-disk and suspend-to-ram.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Christer Weinigel <[EMAIL PROTECTED]> http://www.wei
been very useful for me in real life. So it's
really nice to have both suspend-to-disk and suspend-to-ram.
/Christer
--
Just how much can I get away with and still go to heaven?
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
-
To unsubscribe from this list: send the line
se, this means that a dumb wget won't work all that well to
synchronize two trees, but it might be worthwile anyways.
/Christer
--
"Just how much can I get away with and still go to heaven?"
Freelance consultant specializing in device driver programming for Linux
Christer
to
synchronize two trees, but it might be worthwile anyways.
/Christer
--
Just how much can I get away with and still go to heaven?
Freelance consultant specializing in device driver programming for Linux
Christer Weinigel [EMAIL PROTECTED] http://www.weinigel.se
-
To unsubscribe from
In article <[EMAIL PROTECTED]> I wrote:
>The only problem I can see with this is that it removes one useful thing,
>the ability to give a user access to a whole partition.
>
>chown wingel /dev/hda5
>
>won't work anymore since there is no such device node.
Apologies, this should have gone
In article <[EMAIL PROTECTED]> you
write:
>3. Userspace partition code proposal
>
> Given the above two bits, here's a brief explaination of a
> proposal to move management of the partitioning scheme into
> userspace, along with portions of raid startup, lvm, uuid and
>
In article [EMAIL PROTECTED] you
write:
3. Userspace partition code proposal
Given the above two bits, here's a brief explaination of a
proposal to move management of the partitioning scheme into
userspace, along with portions of raid startup, lvm, uuid and
mount by
In article [EMAIL PROTECTED] I wrote:
The only problem I can see with this is that it removes one useful thing,
the ability to give a user access to a whole partition.
chown wingel /dev/hda5
won't work anymore since there is no such device node.
Apologies, this should have gone to
Alan Cox wrote:
>At most it bounds the busses directly available. I've yet to see VME cardbus
>adapters but its quite possible.
You didn't try google did you? *grin*
http://www.ramix.com/products/busadapters/rm235m.html
/Christer
--
"Just how much can I get away with and still go to
Alan Cox wrote:
At most it bounds the busses directly available. I've yet to see VME cardbus
adapters but its quite possible.
You didn't try google did you? *grin*
http://www.ramix.com/products/busadapters/rm235m.html
/Christer
--
Just how much can I get away with and still go to
1 - 100 of 109 matches
Mail list logo
