Hello Borislav,
Thursday, May 17, 2007, 2:25:54 PM, you wrote:
> -
> From: [EMAIL PROTECTED]
> A very small size (object file 432 bytes smaller) and readability
> optimization of ide.c
And how these "optimizations" fit with BUG_ON() purpose - to
be able to easily identify cause
Hello Borislav,
Thursday, May 17, 2007, 2:25:54 PM, you wrote:
-
From: [EMAIL PROTECTED]
A very small size (object file 432 bytes smaller) and readability
optimization of ide.c
And how these optimizations fit with BUG_ON() purpose - to
be able to easily identify cause and
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
> Robin Getz <[EMAIL PROTECTED]> wrote:
>> On Fri 4 May 2007 16:52, Robert Schwebel pondered:
>>> On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
>>> > We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
>>> >
Hello Bodo,
Sunday, May 6, 2007, 3:19:59 PM, you wrote:
Robin Getz [EMAIL PROTECTED] wrote:
On Fri 4 May 2007 16:52, Robert Schwebel pondered:
On Fri, May 04, 2007 at 02:21:50PM -0400, Robin Getz wrote:
We also have DAC and ADC drivers (up to 16 bits @ 64MS/s, via DMA),
that would be
Hello ian,
Saturday, May 5, 2007, 4:46:26 PM, you wrote:
> On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:
>> Given that USB-power *is* usually also "dumb" (i.e. it doesn't do any
>> control signaling over the USB bus for power-control purposes),
> it might be dumb, but
Hello Anton,
Saturday, May 5, 2007, 3:32:30 PM, you wrote:
> Hello Henrique, Shem,
> On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
>> On Fri, 04 May 2007, Shem Multinymous wrote:
>> > >+enum power_supply_type {
>> > >+ POWER_SUPPLY_TYPE_BATTERY = 0,
>> > >+
Hello Anton,
Saturday, May 5, 2007, 3:32:30 PM, you wrote:
Hello Henrique, Shem,
On Sat, May 05, 2007 at 12:54:13AM -0300, Henrique de Moraes Holschuh wrote:
On Fri, 04 May 2007, Shem Multinymous wrote:
+enum power_supply_type {
+ POWER_SUPPLY_TYPE_BATTERY = 0,
+
Hello ian,
Saturday, May 5, 2007, 4:46:26 PM, you wrote:
On Sat, 2007-05-05 at 00:54 -0300, Henrique de Moraes Holschuh wrote:
Given that USB-power *is* usually also dumb (i.e. it doesn't do any
control signaling over the USB bus for power-control purposes),
it might be dumb, but it is
Hello Greg,
Friday, May 4, 2007, 2:14:59 AM, you wrote:
> On Fri, May 04, 2007 at 01:31:21AM +0400, Anton Vorontsov wrote:
>> This function were placed in "#if 0" because nobody was using it.
>> We using it now.
> Why? Shouldn't you just export the pointer you need instead?
>> See
Hello Greg,
Friday, May 4, 2007, 2:14:59 AM, you wrote:
On Fri, May 04, 2007 at 01:31:21AM +0400, Anton Vorontsov wrote:
This function were placed in #if 0 because nobody was using it.
We using it now.
Why? Shouldn't you just export the pointer you need instead?
See
Hello Dmitry,
Wednesday, May 2, 2007, 12:17:33 AM, you wrote:
> Hello Paul,
> Paul Sokolovsky wrote:
>>> ASIC-related code (I mean core) forms additional platform layer, so I
>>> suggest
>>> adding ASIC helpers to generic platform code i.e. drivers/platform.c
Hello Dmitry,
Wednesday, May 2, 2007, 12:17:33 AM, you wrote:
Hello Paul,
Paul Sokolovsky wrote:
ASIC-related code (I mean core) forms additional platform layer, so I
suggest
adding ASIC helpers to generic platform code i.e. drivers/platform.c, but
ASIC drivers to drivers/asic/ directory
Hello Dmitry,
Tuesday, May 1, 2007, 10:08:23 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
>>> If you used ASIC acronym it would be more appropriate and not so
>>> ambiguous.
>>
>> Actually, thats not bad. I'd be ok with that is SoC isnt used.
>>
>
Hello Richard,
Tuesday, May 1, 2007, 6:01:15 PM, you wrote:
> On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote:
>> Either way, I don't pledge to be a HW designer with
>> contemporary lexicon. The aim was simple - as a single word would be
>> too ambiguous, g
Hello Dmitry,
Tuesday, May 1, 2007, 7:38:44 PM, you wrote:
> ian wrote:
>> On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
>>> Hi Paul,
>>
>>> I think your referring to the term "SoC (system-on-chip)" is confusing
>>> (at least for me). You rather consider companion chips than
Hello Dmitry,
Tuesday, May 1, 2007, 4:53:09 PM, you wrote:
> Hi Paul,
> Paul Sokolovsky wrote:
>> In contemporary systems, lots of functionality oftentimes handled by various
>> kinds of SoCs (system-on-chip), representing a number of deversified
>> controllers packaged
Hello Alan,
Tuesday, May 1, 2007, 1:27:51 PM, you wrote:
>> > + * Copyright 2001 Compaq Computer Corporation.
>> > + *
>> > + * Use consistent with the GNU GPL is permitted,
>> > + * provided that this copyright notice is
>> > + * preserved in its entirety in all copies and derived works.
>> > +
Hello Ben,
Tuesday, May 1, 2007, 11:39:00 AM, you wrote:
> On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote:
[]
>> Initial implementation from few years ago registered per-SoC bus
>> for the purpose of attaching subdevices, but during LKML reviews it
>
Hello Ben,
Tuesday, May 1, 2007, 11:39:00 AM, you wrote:
On Tue, May 01, 2007 at 08:08:06AM +0300, Paul Sokolovsky wrote:
[]
Initial implementation from few years ago registered per-SoC bus
for the purpose of attaching subdevices, but during LKML reviews it
was pointed out that there're
Hello Alan,
Tuesday, May 1, 2007, 1:27:51 PM, you wrote:
+ * Copyright 2001 Compaq Computer Corporation.
+ *
+ * Use consistent with the GNU GPL is permitted,
+ * provided that this copyright notice is
+ * preserved in its entirety in all copies and derived works.
+ *
+ * COMPAQ
Hello Dmitry,
Tuesday, May 1, 2007, 4:53:09 PM, you wrote:
Hi Paul,
Paul Sokolovsky wrote:
In contemporary systems, lots of functionality oftentimes handled by various
kinds of SoCs (system-on-chip), representing a number of deversified
controllers packaged in one chip.
I think your
Hello Dmitry,
Tuesday, May 1, 2007, 7:38:44 PM, you wrote:
ian wrote:
On Tue, 2007-05-01 at 17:53 +0400, Dmitry Krivoschekov wrote:
Hi Paul,
I think your referring to the term SoC (system-on-chip) is confusing
(at least for me). You rather consider companion chips than SoCs.
A 'System'
Hello Richard,
Tuesday, May 1, 2007, 6:01:15 PM, you wrote:
On Tue, 2007-05-01 at 17:36 +0300, Paul Sokolovsky wrote:
Either way, I don't pledge to be a HW designer with
contemporary lexicon. The aim was simple - as a single word would be
too ambiguous, general, or vice-versa
Hello Dmitry,
Tuesday, May 1, 2007, 10:08:23 PM, you wrote:
ian wrote:
On Tue, 2007-05-01 at 20:29 +0400, Dmitry Krivoschekov wrote:
If you used ASIC acronym it would be more appropriate and not so
ambiguous.
Actually, thats not bad. I'd be ok with that is SoC isnt used.
I'm ok with
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
drivers/soc/Kconfig| 22 +
drivers/soc/Ma
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h
Hello linux-kernel,
In contemporary systems, lots of functionality oftentimes handled by various
kinds of SoCs (system-on-chip), representing a number of deversified
controllers packaged in one chip. Handling them is arguably an ongoing
problem, as diversity and number of devices included make
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c
-by: Paul Sokolovsky <[EMAIL PROTECTED]>
include/asm-arm/hardware/ipaq-asic3.h | 609 +
1 files changed, 609 insertions(+), 0 deletions(-)
diff --git a/include/asm-arm/hardware/ipaq-asic3.h
b/include/asm-arm/hardware/ipaq-asic3.h
new file mode 100644
index 0
Hello linux-kernel,
In contemporary systems, lots of functionality oftentimes handled by various
kinds of SoCs (system-on-chip), representing a number of deversified
controllers packaged in one chip. Handling them is arguably an ongoing
problem, as diversity and number of devices included make
Hello linux-kernel,
soc-core: Helper API for SoC base drivers to register/unregister
subdevices.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
arch/arm/Kconfig |2 +
drivers/Makefile |1 +
drivers/soc/soc-core.c | 106
-by: Paul Sokolovsky [EMAIL PROTECTED]
include/asm-arm/hardware/ipaq-asic3.h | 609 +
1 files changed, 609 insertions(+), 0 deletions(-)
diff --git a/include/asm-arm/hardware/ipaq-asic3.h
b/include/asm-arm/hardware/ipaq-asic3.h
new file mode 100644
index 000
Hello linux-kernel,
Note: This driver depends on ds1wm.h header, recently submitted, and which by
now should be in -mm tree.
-
asic3_base: SoC base driver for ASIC3 chip.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
drivers/soc/Kconfig| 22 +
drivers/soc/Makefile
Hello linux-kernel,
mach-rx3715: Add support for builtin ASIC3 chip, based on the
asic3_base driver.
arch/arm/mach-s3c2440/mach-rx3715.c | 84 +++
include/asm-arm/arch-s3c2410/rx3000-asic3.h | 63
include/asm-arm/arch-s3c2410/rx3000.h
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>> >> > So, talking about what an (optional) implementation framework might
>> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
>> >> > I've looked at):
>>
>> > See patches in following messages ... a
Hello David,
Thursday, April 19, 2007, 5:22:44 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
See patches in following messages ... a preliminary gpio_chip core
Hello David,
Sunday, April 15, 2007, 10:47:57 PM, you wrote:
> On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
>> Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
>> > So, talking about what an (optional) implementation framework might
>> > look like (and
Hello David,
Sunday, April 15, 2007, 10:47:57 PM, you wrote:
On Thursday 12 April 2007 6:57 am, Paul Sokolovsky wrote:
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
> On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
>> +static void (*old_apm_get_power_status)(struct apm_power_info*);
>> +
>> +static int __init apm_battery_init(void)
>> +{
>> + printk(KERN_INFO "APM Battery
Hello Russell,
Monday, April 16, 2007, 11:24:21 PM, you wrote:
On Fri, Apr 13, 2007 at 05:50:43PM +0400, Anton Vorontsov wrote:
+static void (*old_apm_get_power_status)(struct apm_power_info*);
+
+static int __init apm_battery_init(void)
+{
+ printk(KERN_INFO APM Battery Driver\n);
+
Hello Matthew,
Thursday, April 12, 2007, 5:24:30 PM, you wrote:
> On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote:
>> On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote:
>> > ACPI batteries can report capacity and rate in either mA or mW. Given
>>
>> You sure,
Hello Juergen,
Wednesday, April 11, 2007, 9:47:01 AM, you wrote:
> Am Dienstag, 10. April 2007 23:30 schrieb Paul Sokolovsky:
>> Hello linux-arm-kernel,
>>
>> GPIODEV API: Core API definitions. Provided are:
>> 1. struct gpiodev_ops which must be included i
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
> On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>>
>> > /* defined by the platform using array, if/else/..., IDR, or
>> > whatever */
>> > struct gpio_yyy *gpio_to_yy
Hello David,
Wednesday, April 11, 2007, 7:52:20 AM, you wrote:
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
/* defined by the platform using array, if/else/..., IDR, or
whatever */
struct gpio_yyy *gpio_to_yyy(unsigned gpio);
I assume by platform you
Hello Juergen,
Wednesday, April 11, 2007, 9:47:01 AM, you wrote:
Am Dienstag, 10. April 2007 23:30 schrieb Paul Sokolovsky:
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which
Hello Matthew,
Thursday, April 12, 2007, 5:24:30 PM, you wrote:
On Thu, Apr 12, 2007 at 06:15:05PM +0400, Anton Vorontsov wrote:
On Thu, Apr 12, 2007 at 02:08:18PM +0100, Matthew Garrett wrote:
ACPI batteries can report capacity and rate in either mA or mW. Given
You sure, capacity in mA?
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
> it looks ok, but I have several questions:
> 1. why should we bind this to platform_device, what if the gpio device
> is not actually a "platform_device", say, a I2C device, a SPI device or
> even a USB device?
Good point. That
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
> On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
>> > Nobody who really wants to have such an implementation framework has yet
>> > ponied up and done the work to make one.
>>
>> Well, sorr
-type=text/plain=h
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: include/linux/soc/asic3_base.h
===
RCS file: include/linux/soc/asic3_base.h
diff -N include/linux/soc/asic3_base.h
--- /dev/null 1 Jan 1970 00:00:00
s approach is
followed for GPIODEV too.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: arch/arm/mach-pxa/generic.c
===
RCS file: /cvs/linux/kernel26/arch/arm/mach-pxa/generic.c,v
retrieving revision 1.39
retrieving revis
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO
Hello Kernel lists,
This is updated and reworked API previously proposed at
http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback
(suggestions to use established kernel terminology/naming convention
and drop macros). There are also actual tested patches provided this
time,
Hello Kernel lists,
This is updated and reworked API previously proposed at
http://lkml.org/lkml/2007/3/27/63 . In incorporates received feedback
(suggestions to use established kernel terminology/naming convention
and drop macros). There are also actual tested patches provided this
time,
Hello linux-arm-kernel,
GPIODEV API: Core API definitions. Provided are:
1. struct gpiodev_ops which must be included into platform_data structure
of a device which will provide GPIODEV API; driver for a device must
initialize this structure.
2. Structural definition of generalized GPIO
is
followed for GPIODEV too.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: arch/arm/mach-pxa/generic.c
===
RCS file: /cvs/linux/kernel26/arch/arm/mach-pxa/generic.c,v
retrieving revision 1.39
retrieving revision 1.41
diff -u -r1.39
-type=text/plainf=h
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: include/linux/soc/asic3_base.h
===
RCS file: include/linux/soc/asic3_base.h
diff -N include/linux/soc/asic3_base.h
--- /dev/null 1 Jan 1970 00:00:00 -
Hello David,
Monday, April 9, 2007, 11:22:25 PM, you wrote:
On Monday 09 April 2007 10:18 am, Paul Sokolovsky wrote:
Nobody who really wants to have such an implementation framework has yet
ponied up and done the work to make one.
Well, sorry if it wasn't made clear, but we
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
it looks ok, but I have several questions:
1. why should we bind this to platform_device, what if the gpio device
is not actually a platform_device, say, a I2C device, a SPI device or
even a USB device?
Good point. That was
Hello H.,
Wednesday, March 28, 2007, 7:32:57 PM, you wrote:
> Paul Sokolovsky wrote:
>>
>> In this respect, VTABLE(), METHOD() macros serve the same purpose as
>> container_of() and list_for_each() - they are besides offering (more)
>> convenient syntax, also
Hello H.,
Wednesday, March 28, 2007, 7:32:57 PM, you wrote:
Paul Sokolovsky wrote:
In this respect, VTABLE(), METHOD() macros serve the same purpose as
container_of() and list_for_each() - they are besides offering (more)
convenient syntax, also carry important annotattion
Hello LKML,
We, HandHelds.org, for quite some time are working on generilized support
for consumer handheld devices (with primary focus on ARM-based PocketPC's
ans smartphones). While we made big progress in many areas, we still
were no able to put all the part of riddle together, producing clean
Hello LKML,
We, HandHelds.org, for quite some time are working on generilized support
for consumer handheld devices (with primary focus on ARM-based PocketPC's
ans smartphones). While we made big progress in many areas, we still
were no able to put all the part of riddle together, producing clean
Hello NZG,
Tuesday, March 6, 2007, 8:46:29 PM, you wrote:
> I'm developing an SPI- bus >MMC/SD block driver translation layer.
> As part of this layer the write protect and card detect lines need to be read.
> The method for determining the state of these lines will be board specific.
> Is it
Hello NZG,
Tuesday, March 6, 2007, 8:46:29 PM, you wrote:
I'm developing an SPI- bus MMC/SD block driver translation layer.
As part of this layer the write protect and card detect lines need to be read.
The method for determining the state of these lines will be board specific.
Is it
Hello Rodolfo,
Thursday, February 22, 2007, 10:32:04 AM, you wrote:
> On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote:
k>> Why? It's the same, except that it already exists, generic one (not
>> limited to pxafb), and requires 1 function (too bad that C doe
Hello Rodolfo,
Thursday, February 22, 2007, 10:32:04 AM, you wrote:
On Wed, Feb 21, 2007 at 06:26:08PM +0200, Paul Sokolovsky wrote:
k Why? It's the same, except that it already exists, generic one (not
limited to pxafb), and requires 1 function (too bad that C doesn't
support lambda's
Hello Rodolfo,
Wednesday, February 21, 2007, 6:12:10 PM, you wrote:
> On Wed, Feb 21, 2007 at 06:00:37PM +0200, Paul Sokolovsky wrote:
>>
>> On the other hand, there's already
>> drivers/video/backlight/backlight.c which provides generic BL support,
>> implemen
Hello Rodolfo,
Wednesday, February 21, 2007, 6:02:13 PM, you wrote:
> Hello,
> I'd like to add backlight support for input devices since my custom
> board has a backlighted mini keyboard.
There's already generic indicator API, currently mostly known as
"[new] LED [classdev] API", even though
Hello Rodolfo,
Wednesday, February 21, 2007, 4:53:53 PM, you wrote:
> Backlight control support for the PXA fram buffer.
Here're some comments: backlight support is already confusing
matter, and your patch IMHO makes it even more confusing for PXAFB.
Before even start with details, let's
Hello Rodolfo,
Wednesday, February 21, 2007, 4:53:53 PM, you wrote:
Backlight control support for the PXA fram buffer.
Here're some comments: backlight support is already confusing
matter, and your patch IMHO makes it even more confusing for PXAFB.
Before even start with details, let's
Hello Rodolfo,
Wednesday, February 21, 2007, 6:02:13 PM, you wrote:
Hello,
I'd like to add backlight support for input devices since my custom
board has a backlighted mini keyboard.
There's already generic indicator API, currently mostly known as
[new] LED [classdev] API, even though it
Hello Rodolfo,
Wednesday, February 21, 2007, 6:12:10 PM, you wrote:
On Wed, Feb 21, 2007 at 06:00:37PM +0200, Paul Sokolovsky wrote:
On the other hand, there's already
drivers/video/backlight/backlight.c which provides generic BL support,
implemented using notifier callback for FB core
Hello David,
Tuesday, December 19, 2006, 2:59:11 AM, you wrote:
> On Monday 18 December 2006 4:54 pm, David Brownell wrote:
>> > http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5=1.6=h
>>
>> That patch you applied looks right to me -- why don't you
Hello David,
Monday, December 18, 2006, 6:28:58 AM, you wrote:
> On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote:
>> Small battery-powered systems, like PDAs, need a way to be
>> suspended most of the time and woken up just from time to time to
>>
Hello David,
Monday, December 18, 2006, 6:28:58 AM, you wrote:
On Sunday 17 December 2006 11:30 am, Paul Sokolovsky wrote:
Small battery-powered systems, like PDAs, need a way to be
suspended most of the time and woken up just from time to time to
process pending tasks.
Sounds like
Hello David,
Tuesday, December 19, 2006, 2:59:11 AM, you wrote:
On Monday 18 December 2006 4:54 pm, David Brownell wrote:
http://handhelds.org/cgi-bin/cvsweb.cgi/linux/kernel26/drivers/rtc/rtc-sa1100.c.diff?r1=1.5r2=1.6f=h
That patch you applied looks right to me -- why don't you forward
ial try to implement it.
Formal part
===
Implement "alarm" attribute group for RTC classdevs. At this time,
add "since_epoch", "wakeup_enabled", and "pending" attributes. First
two support both read and write.
Signed-off-by: Paul Sok
Hello linux-kernel,
Well, this was (at least) since 2.6.18, so I guess, someone
should finally submit it patch for it. And yes, kbuild parses that,
but that doesn't make it not typo, right?
--- drivers/rtc/Kconfig 2 Dec 2006 02:18:35 - 1.3
+++ drivers/rtc/Kconfig 17 Dec 2006
Hello linux-kernel,
Well, this was (at least) since 2.6.18, so I guess, someone
should finally submit it patch for it. And yes, kbuild parses that,
but that doesn't make it not typo, right?
--- drivers/rtc/Kconfig 2 Dec 2006 02:18:35 - 1.3
+++ drivers/rtc/Kconfig 17 Dec 2006
it.
Formal part
===
Implement alarm attribute group for RTC classdevs. At this time,
add since_epoch, wakeup_enabled, and pending attributes. First
two support both read and write.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: drivers/rtc/rtc-sysfs.c
Hello Lennert,
Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
[]
> (These
> days I build all kernels in EABI mode with old-ABI compat.) I have
> not run into any code generation issues with this compiler yet.
I wonder, if OABI-compat is known to actually work on OABI userspace,
I mean,
.
Signed-off-by: Paul Sokolovsky <[EMAIL PROTECTED]>
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/ne
.
Signed-off-by: Paul Sokolovsky [EMAIL PROTECTED]
Index: drivers/net/irda/pxaficp_ir.c
===
RCS file: /cvs/linux/kernel26/drivers/net/irda/pxaficp_ir.c,v
retrieving revision 1.3
diff -u -r1.3 pxaficp_ir.c
--- drivers/net/irda
Hello Lennert,
Wednesday, December 6, 2006, 3:08:13 AM, you wrote:
[]
(These
days I build all kernels in EABI mode with old-ABI compat.) I have
not run into any code generation issues with this compiler yet.
I wonder, if OABI-compat is known to actually work on OABI userspace,
I mean, on
Hello Jiri,
Monday, November 20, 2006, 1:45:51 AM, you wrote:
> Paul Sokolovsky wrote:
>> But alas, the commit message is not as good as some others are, and
>> doesn't mention what should be used instead. So, if find_bus() is
>> "unused", what should be used
Hello linux-kernel,
We here at Handhelds.org upgrading our drivers to 2.6.18 and I just
caught a case of find_bus() being undefined during link. Quickly
traced this to
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5
Hello linux-kernel,
We here at Handhelds.org upgrading our drivers to 2.6.18 and I just
caught a case of find_bus() being undefined during link. Quickly
traced this to
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7e4ef085ea4b00cfc34e854edf448c729de8a0a5
Hello Jiri,
Monday, November 20, 2006, 1:45:51 AM, you wrote:
Paul Sokolovsky wrote:
But alas, the commit message is not as good as some others are, and
doesn't mention what should be used instead. So, if find_bus() is
unused, what should be used instead?
You should probably mention what
88 matches
Mail list logo
