Tejun Heo wrote:
Kumar Gala wrote:
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Tejun Heo <[EMAIL PROTECTED]>
Fine with me,
Kumar Gala wrote:
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
Acked-by: Tejun Heo <[EMAIL PROTECTED]>
Thanks.
--
tejun
__
My test builds for efika currently fail with this message:
FATAL: drivers/serial/mpc52xx_uart: struct of_device_id is not terminated with
a NULL entry!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [sub-make] Error 2
Could you do a little patch to add the NULL entry p
Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
include/linux/io.h |4 ++--
lib/devres.c |4 ++--
2 files changed, 4 inserti
On Tue, 29 Apr 2008 15:08:29 +1000
"Paul Mackerras" <[EMAIL PROTECTED]> wrote:
> It doesn't help that both of these patches have the same subject line,
> nor that it starts with "Re:". :(
Sorry about that. I just split up the two patches, but the same subject
does apply to both. The code currentl
From: Etienne Bersac <[EMAIL PROTECTED]>
Implement a new driver named windfarm_pm121 which drive fans on PowerMac
12,1 machine : iMac G5 iSight (rev C) 17" and 20". It's based on
windfarm_pm81 driver from Benjamin Herrenschmidt.
Signed-off-by: Etienne Bersac <[EMAIL PROTECTED]>
Signed-off-by: Dav
Make iommu_map_sg take a struct iommu_table. It did so before commit
740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
iommu respect the segment size limits).
This stops the function looking in the archdata.dma_data for the iommu
table because in the future it will be called w
It doesn't help that both of these patches have the same subject line,
nor that it starts with "Re:". :(
Also, I find the statement "A change to the dts to get gpios correct
broke the led code" a bit opaque. It doesn't tell me in what way it
was broken or what this patch does to correct, or even
I wrote:
> +7: rlwinm r12,r12,0,~TLF_SLEEPING
That should be rlwinm r12,r12,0,~_TLF_SLEEPING (with the leading
underscore), of course. Thanks to Stephen Rothwell for pointing that
out.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
htt
Scott Wood writes:
> On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote:
> > is there any specific reason, why out of these 7 patches only the first
> > one made it into the mainline? AFAICS, there has been only one comment,
> > suggesting to replace printk with dev_err on two
> -Original Message-
> From: Gala Kumar
> Sent: Tuesday, April 22, 2008 9:38 PM
> To: Jin Zhengxiong
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH v2] MSI driver for Freescale 83xx/85xx/86xx cpu
>
> > diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/
> > Makefile
A change to the dts to get gpios correct broke the led code.
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
PIKA Warp: Update DTS to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Added led entries.
* Added fpga-sd entry.
* Added ad7414 entry.
Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
diff --git a/arch/powerpc/boot/dts/wa
Christoph Hellwig writes:
> Am I missing something here or does this add a branch for every normal
> syscall?
It does, but the impact is so small as to be unmeasurable with
lmbench, even on the null syscall measurement. The overhead of the
easily-predicted not-taken branch is completely swamped
On Mon, Apr 28, 2008 at 7:50 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
> index b04a52e..3e95e99 100644
You still need to have *some* kind of change log and a signed-off-by
line in this patch. :-)
There is one min
Hi Remi,
On Mon, 28 Apr 2008 10:12:09 -0700 Remi Machet <[EMAIL PROTECTED]> wrote:
>
> +static struct of_device_id of_mv64x60_devices[] = {
__initdata, please.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpAmX071fC3E.pgp
Description: PGP
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..3e95e99 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
[EMAIL PROTECTED],0 {
Ok, I think I have everybodys changes in. I will split out the DTS into
a separate patch. The changelog is in this one.
Cheers,
Sean
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
Kamalesh Babulal ([EMAIL PROTECTED]) reports that CONFIG_NVRAM=m
is valid in terms of Kconfig but fails to build with:
Building modules, stage 2.
MODPOST 1401 modules
ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] undefined!
ERROR: "__alloc_bootmem" [arch/powerpc/platforms/po
Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
arch/powerp
On Fri, Apr 25, 2008 at 04:12:50PM +1000, Benjamin Herrenschmidt wrote:
> Considering how bad OF can be on some machines, I'd like this to be
> boot-tested on a wider range of machines. Also, it might depend on the
> OF real-base setting as well...
>
> At least, we should be able to test at ozlab
thanks, applied
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
On Mon, Apr 28, 2008 at 3:37 PM, Sean MacLennan <[EMAIL PROTECTED]> wrote:
> On Mon, 28 Apr 2008 13:56:11 -0600
>
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> >
>
> > You need to add the gpio-controller and #gpio-cells properties to the
> > GPIO nodes for the LED's gpios property to work corre
On Mon, 28 Apr 2008 16:54:24 -0500
Scott Wood <[EMAIL PROTECTED]> wrote:
> Why can't the existing partition binding be used with NAND? It's
> what we do with Freescale FCM NAND.
I guess I could put the partitions in the dts. But I would have to
read them and dynamically create an array to pass t
On Mon, Apr 28, 2008 at 05:37:38PM -0400, Sean MacLennan wrote:
> > Why is this information in the dts *and* the platform file? I haven't
> > been following the flash partition map binding conventions, but having
> > it in both places looks wrong
> >
> > oh, wait... the one in the dts is for
On Mon, 2008-04-28 at 17:24 -0400, Sean MacLennan wrote:
> On Mon, 28 Apr 2008 21:44:05 +0100
> "Richard Purdie" <[EMAIL PROTECTED]> wrote:
>
> > You can leave sections blank but it pays to leave the separator in so
> > use ":red:" or ":red", not "red".
>
> Ok, :red: and :green: it is.
>
> What
On Mon, 28 Apr 2008 13:56:11 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> You need to add the gpio-controller and #gpio-cells properties to the
> GPIO nodes for the LED's gpios property to work correctly. Search for
> "2) gpio-controller nodes" in
> Documentation/powerpc/booting-without-o
On Mon, 28 Apr 2008 21:44:05 +0100
"Richard Purdie" <[EMAIL PROTECTED]> wrote:
> You can leave sections blank but it pays to leave the separator in so
> use ":red:" or ":red", not "red".
Ok, :red: and :green: it is.
What would be the advantage of pika:red: or warp:red:?
Cheers,
Sean
_
On Mon, 2008-04-28 at 13:59 -0400, Sean MacLennan wrote:
> On Mon, 28 Apr 2008 11:44:19 -0600
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
> > This looks appropriate. You'll need to make sure that the values in
> > the linux,name property meet the Linux LED naming guidelines. I think
> > this
On Mon, Apr 28, 2008 at 01:36:10PM -0700, Badari Pulavarty wrote:
> Hi Greg,
>
> Ran into this sysfs oops while booting 2.6.25-git12.
It's not an "oops" but a WARN_ON(1);
> ipr issue ?
Stupid driver issue, yes:
> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
> ipr
On Sun, Apr 06, 2008 at 10:16:07PM +0200, Segher Boessenkool wrote:
> PowerPC will start moving board defconfigs into subarch-specific
> subdirs soon. "make help" currently does not look in subdirs to
> find the defconfigs to show. This is partially a good thing,
> since there are way too many de
Hi Greg,
Ran into this sysfs oops while booting 2.6.25-git12.
ipr issue ?
Thanks,
Badari
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr :d0:01.0: Found IOA with IRQ: 119
ipr :d0:01.0: Starting IOA initialization sequence.
ipr :d0:01.0: Adapter firmware ver
On Mon, Apr 28, 2008 at 11:26:15AM -0500, Rune Torgersen wrote:
> Examples would be the FCC's on a Freescale PQ2 chip, where they are
> encoded as ethernet controllers. (Thsy could be used as high-speed HDLC
> controllers, ATM controllers and other usages), the SCC ports (as
> serial, they can be u
On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote:
> is there any specific reason, why out of these 7 patches only the first
> one made it into the mainline? AFAICS, there has been only one comment,
> suggesting to replace printk with dev_err on two occasions in one of
> the
Hi Wolfram,
> I tested on this hardware
>
> MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor)
> + RS5C372 (rtc) + X24645 (eeprom)
It's also OK on dbox2 hardware: MPC823 (powerpc)
+ saa7127 (patch needed to add id_table) + dbox frontprocessor
(8051 controller with i2c interface).
Thank
Olaf Hering wrote:
> On Sun, Feb 10, Alexey Dobriyan wrote:
>
> > On Sun, Feb 10, 2008 at 11:07:57AM +0100, Olaf Hering wrote:
> > > Current Linus tree gives this new warning during bootup:
> > >
> > > +proc_dir_entry '00' already registered
> > > +Call Trace:
> > > +[c0007b0dfba0] [c
On Mon, Apr 28, 2008 at 12:53 PM, Sean MacLennan
<[EMAIL PROTECTED]> wrote:
> Ok, here is another version of the patch with Stephen Rothwell's and
> Grant Likely's suggestions.
>
> Cheers,
> Sean
A few more comments below.
Also, it might help to split up the .dts and code changes into 2
separ
On Mon, Apr 28, 2008 at 02:20:44PM +1000, Tony Breeds wrote:
> On Sun, Apr 27, 2008 at 08:03:46PM +0200, Christian Kujau wrote:
> > Hi,
> >
> > the build failure reported[0] by Kamalesh back in 01/2008 is still
> > present in today's 2.6.25-git with CONFIG_NVRAM=m (instead of =y):
> >
> > Buil
On Mon, Apr 28, 2008 at 12:22:36PM -0700, Remi Machet wrote:
> On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> > On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > > For each mv64360 entry in the OpenFir
On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > For each mv64360 entry in the OpenFirmware database, add the
> > registration of an of_bus to take care o
Ok, here is another version of the patch with Stephen Rothwell's and
Grant Likely's suggestions.
Cheers,
Sean
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST informatio
On Mon, Apr 28, 2008 at 05:39:32PM +0200, Guennadi Liakhovetski wrote:
> This is a driver for the mpc83xx's GTM4 timer. It's functionality
> is limited to providing a wakeup source for suspend-to-RAM.
This driver should be redone as a client of Anton's more general GTM
driver.
-Scott
___
On Fri, Apr 25, 2008 at 07:09:59PM +0800, Li Yang wrote:
> The error can also be soft error like a typo in the cmdline or device
> tree. I could be better to try other ways to see if we can find a sane
> partition table than just to fail.
If cmdline partition information exists, typo or not, then
On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> For each mv64360 entry in the OpenFirmware database, add the
> registration of an of_bus to take care of devices connected to
> the MV64x60 asynchronous devices controll
On Apr 28, 2008, at 12:04 PM, Scott Wood wrote:
On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
A few possibilities:
* introduce an additional function pointer as part of
E
On Mon, 28 Apr 2008 11:44:19 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> This looks appropriate. You'll need to make sure that the values in
> the linux,name property meet the Linux LED naming guidelines. I think
> this is covered in Documentation/leds-class.c. You can also as
> Richard P
On Mon, Apr 28, 2008 at 11:10 AM, Sean MacLennan
<[EMAIL PROTECTED]> wrote:
> On Sun, 27 Apr 2008 22:47:43 -0600
>
> "Grant Likely" <[EMAIL PROTECTED]> wrote:
>
>
> > If your LEDs are attached to gpio pins, then you should use the
> > current draft led->gpio bindings as shown in the above patch.
Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
Signed-off-by: Remi Machet ([EMAIL PROTECTED])
---
I did not mod
On Sun, 27 Apr 2008 22:47:43 -0600
"Grant Likely" <[EMAIL PROTECTED]> wrote:
> If your LEDs are attached to gpio pins, then you should use the
> current draft led->gpio bindings as shown in the above patch. Then,
> let your platform code extract whatever data it needs from the device
> tree to se
On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
>
> On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
> >On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> >>A few possibilities:
> >>* introduce an additional function pointer as part of
> >>EXC_XFER_TEMPLATE() to specifies the
On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
A few possibilities:
* introduce an additional function pointer as part of
EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
dbg, mcheck)
* use the traps field low order
Signed-off-by: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_eq.c | 35 -
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c
b/drivers/infiniband/hw/ehca/ehca_eq.c
index b4ac617..49660d
Laurent Pinchart wrote:
> Last thing I heard was that the device tree should not encode
> a device's
> expected usage, so memory nodes should not have any
> compatible property that
> would automatically associated them to an MTD driver. I've
> been adviced to
> add platform-specific code to instan
On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote:
> On Mon, 28 Apr 2008 17:07:25 +0200, Kay Sievers wrote:
> > On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote:
> > > One thing I am still not happy with is that the aliases created have a
> > > trailing "*":
> > >
> > > $ /sbin/modinfo lm
Hello Jean,
I tested on this hardware
MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor)
+ RS5C372 (rtc) + X24645 (eeprom)
the following software
2.6.25-git11 + your 2 patches + Patches 5-7 from Jochen's series
(for the CPM2-bus-driver)
The rtc and the eeprom were assigend through o
On Mon, Apr 28, 2008 at 4:43 PM, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> Please see Michael Kerrisk on userspace ABI updates. A nice little
> manpage for this gimmick would be helpful, and maybe help other
> platforms that want one aswell to implement the same API.
Thanks Chrsitoph. I'm n
On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> A few possibilities:
> * introduce an additional function pointer as part of
> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
> dbg, mcheck)
> * use the traps field low order bits to determine normal, crit, dbg,
On Mon, Apr 28, 2008 at 05:40:19PM +0200, Guennadi Liakhovetski wrote:
> +static int ls_pm_enter(suspend_state_t state)
> +{
> + u64 tb;
> +
> + /* Get timebase */
> + tb = get_tb();
> +
> + /* put CPU to sleep, re-enabling interrupts */
> + mpc6xx_enter_standby();
> +
> + l
Hi Jon,
On Mon, 28 Apr 2008 10:43:35 -0400, Jon Smirl wrote:
> On 4/28/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> > One thing I am still not happy with is that the aliases created have a
> > trailing "*":
> >
> > $ /sbin/modinfo lm90
> > filename: /lib/modules/2.6.25-git11/kernel/driv
I'm looking at fixing an issue parts that have multiple exception
levels (e300, 40x, booke).
One of the issues is the transfer_to_handler patch in entry_32.S
doesn't use the proper save/restore registers to transfer to C code.
The following bit of code is what I'm having issues with:
Hi Kay,
On Mon, 28 Apr 2008 17:07:25 +0200, Kay Sievers wrote:
> On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote:
> > One thing I am still not happy with is that the aliases created have a
> > trailing "*":
> >
> > $ /sbin/modinfo lm90
> > filename: /lib/modules/2.6.25-git11/kernel/dr
Implement suspend/resume for "mpc10x" compatible fsl host PCI controllers,
use it for linkstation standby. This is version 3, updated to the current
powerpc git tree. Depends as before on TLF_SLEEPING and HID0_SLEEP patches
from Scott Wood.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
This patch has already been acked by Jeff Garzik:
>From [EMAIL PROTECTED] Fri Dec 14 20:28:38 2007
Date: Fri, 14 Dec 2007 15:24:29 -0500
From: Jeff Garzik <[EMAIL PROTECTED]>
To: Scott Wood
The magic packet flag indicates that the hardware has this
capability. The MDIO flag indicates that this device's
registers contain active MDIO registers, and thus this
device should not be put to sleep.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PR
This is a driver for the mpc83xx's GTM4 timer. It's functionality
is limited to providing a wakeup source for suspend-to-RAM.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/Kconfig |9 +
arch/powerpc/pla
Basic PM support for 83xx. Standby is implemented as sleep.
Suspend-to-RAM is implemented as "deep sleep" (with the processor
turned off) on 831x.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
The enabling of i-cache at the end of the s
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/6xx-suspend.S | 52 +
arch/powerpc/sysdev/Makefile |4 +++
include/asm-powerpc/mpc6xx.h |6
3 files changed, 6
The e300 core (and probably most other 6xx chips) can only come out of
sleep mode with an interrupt. However, interrupts are logically disabled
by the power management layer.
This hack extends the existing doze/nap hack to also suppress the running
of the interrupt handler when in sleep mode.
Si
Hi all
as replies to this email I'm going to post a respin of the last version
from December 2007 of Scott's patches plus my patch for Linkstation
standby.
Scott, I upgraded your patches, please, verify, that they still function.
I added my Sof's as I'm now forwarding them, I believe, this is
On Sun, Apr 27, 2008 at 08:35:51PM +0200, Christian Kujau wrote:
> I was a bit puzzled today when I came across
> /sys/devices/platform/pmu-battery.0/power_supply/PMU battery 0/power
> and thought to myself: why are there spaces in "PMU battery 0"?
Why not?
> Wouldn't ../pmu-battery.0/power_suppl
On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote:
> Based on earlier work by Jon Smirl and Jochen Friedrich.
>
> This patch allows new-style i2c chip drivers to have alias names using
> the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
> point, the old i2c driver binding
Please see Michael Kerrisk on userspace ABI updates. A nice little
manpage for this gimmick would be helpful, and maybe help other
platforms that want one aswell to implement the same API.
On Mon, Apr 28, 2008 at 01:52:31PM +1000, Paul Mackerras wrote:
> This adds a system call on 64-bit platform
On 4/28/08, Jean Delvare <[EMAIL PROTECTED]> wrote:
> Based on earlier work by Jon Smirl and Jochen Friedrich.
>
> This patch allows new-style i2c chip drivers to have alias names using
> the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
> point, the old i2c driver binding s
Based on earlier work by Jon Smirl and Jochen Friedrich.
Update most new-style i2c drivers to use standard module aliasing
instead of the old driver_name/type driver matching scheme. I've
left the video drivers apart (except for SoC camera drivers) as
they're a bit more diffcult to deal with, they
Based on earlier work by Jon Smirl and Jochen Friedrich.
This patch allows new-style i2c chip drivers to have alias names using
the official kernel aliasing system and MODULE_DEVICE_TABLE(). At this
point, the old i2c driver binding scheme (driver_name/type) is still
supported.
Signed-off-by: Jea
Hi all,
This is an updated, minimal patchset to add support for device alias
names to the i2c subsystem. It is based on earlier work by Jon Smirl,
Jochen Friedrich and myself.
For 2.6.26-rc1 I'll only attempt to push the first two patches: the one
adding the support for alias names and the one co
On Thu, Apr 24, 2008 at 11:27:37AM +0200, Johannes Berg wrote:
> On Thu, 2008-04-24 at 02:24 -0700, David Miller wrote:
> > From: Johannes Berg <[EMAIL PROTECTED]>
> > Date: Thu, 24 Apr 2008 11:21:52 +0200
> >
> > > Hmm. Why is that whole cpu_clock stuff in place anyway? powerpc has
> > > perfectl
> Thanks. That can't go in until some generic changes have gone in
> first, right? So are you going to push the lot in one go via Andrew,
> or should I wait until the generic part is upstream and then push the
> powerpc bit?
>From what I can see, the related patches are in -mm now, but the power
78 matches
Mail list logo
