* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2009-04-22 5:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug fixes for powerpc, plus some documentation and
defconfig updates and a MAINTAINERS update.
Thanks,
Paul.
Documentation/powerpc/booting-without-of.txt | 89 -
Documentation/powerpc/dts-bindings/mtd-physmap.txt | 80 +
MAINTAINERS | 5=20
arch/powerpc/boot/dts/lite5200b.dts | 39=20
arch/powerpc/configs/52xx/cm5200_defconfig | 69 +
arch/powerpc/configs/52xx/lite5200b_defconfig | 74 +
arch/powerpc/configs/52xx/motionpro_defconfig | 77 +
arch/powerpc/configs/52xx/pcm030_defconfig | 69 +
arch/powerpc/configs/52xx/tqm5200_defconfig | 76 +
arch/powerpc/configs/85xx/mpc8536_ds_defconfig | 1802 ------------=
--------
arch/powerpc/configs/85xx/mpc8544_ds_defconfig | 1802 ------------=
--------
arch/powerpc/configs/85xx/mpc8568mds_defconfig | 1309 ------------=
---
arch/powerpc/configs/mpc5200_defconfig | 188 ++
arch/powerpc/configs/mpc85xx_defconfig | 252 +--
arch/powerpc/configs/mpc85xx_smp_defconfig | 343 ++--
arch/powerpc/include/asm/elf.h | 3=20
arch/powerpc/kernel/prom_parse.c | 11=20
arch/powerpc/mm/hash_utils_64.c | 2=20
arch/powerpc/platforms/fsl_uli1575.c | 5=20
arch/powerpc/platforms/pasemi/setup.c | 4=20
arch/powerpc/platforms/ps3/os-area.c | 2=20
arch/powerpc/sysdev/fsl_rio.c | 28=20
drivers/macintosh/Kconfig | 2=20
drivers/macintosh/mediabay.c | 2=20
include/linux/fsl_devices.h | 4=20
25 files changed, 896 insertions(+), 5441 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/mtd-physmap.txt
delete mode 100644 arch/powerpc/configs/85xx/mpc8536_ds_defconfig
delete mode 100644 arch/powerpc/configs/85xx/mpc8544_ds_defconfig
delete mode 100644 arch/powerpc/configs/85xx/mpc8568mds_defconfig
rename arch/powerpc/configs/{85xx/mpc8572_ds_defconfig =3D> mpc85xx_sm=
p_defconfig} (91%)
Alexander Beregalov (1):
powerpc: Make macintosh/mediabay driver depend on CONFIG_BLOCK
Andreas Schwab (1):
powerpc/32: Don't clobber personality flags on exec
Anton Vorontsov (2):
powerpc/5200: Bring the legacy fsl_spi_platform_data hooks back
fsl_rio: Pass the proper device to dma mapping routines
Bartlomiej Zolnierkiewicz (1):
powerpc: Fix modular build of ide-pmac when mediabay is built in
Geoff Levand (3):
powerpc/ps3: Fix CONFIG_PS3_FLASH=3Dn build warning
maintainers: Fix PS3 patterns
powerpc/pasemi: Fix build error on UP
Grant Likely (2):
powerpc/5200: Add FLASH nodes to lite5200 device tree
powerpc/5200: defconfig updates
Ilpo J=E4rvinen (1):
powerpc: Fix of_node_put() exit path in of_irq_map_one()
Kumar Gala (4):
powerpc/85xx: Updated generic mpc85xx_defconfig
powerpc/85xx: Enabled a bunch of FSL specific drivers/options
powerpc/85xx: Added SMP defconfig
powerpc/85xx: Remove defconfigs that mpc85xx_{smp_}defconfig cove=
r
Michael Ellerman (1):
powerpc: Fix crash on CPU hotplug
Stefan Roese (2):
powerpc/of-device-tree: Factor MTD physmap bindings out of bootin=
g-without-of
powerpc/device-tree: Document MTD nodes with multiple "reg" tuple=
s
Timur Tabi (1):
powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD
^ permalink raw reply
* Java Runtime Environment on mpc8347
From: yamazaki seiji @ 2009-04-22 7:23 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: linuxppc-dev
In-Reply-To: <3A45394FD742FA419B760BB8D398F9ED2FAE0B@zch01exm26.fsl.freescale.net>
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have a plan of running Java on my PPC8347 BRD.
I have read the article about Java on Freescale processor before.
Do you know how to get it?
--
yamazaki seiji <yamazaki.seiji@kk.jp.panasonic.com>
^ permalink raw reply
* Re: [BUILD FAILURE 11/12] Next April 21 : PPC64 randconfig [drivers/usb/host/ohci-hcd.o]
From: Arnd Bergmann @ 2009-04-22 7:30 UTC (permalink / raw)
To: Randy Dunlap
Cc: sachinp, Stephen Rothwell, samr, linux-usb, linux-kernel,
David Brownell, Linuxppc-dev, linux-next, subrata,
Alexander Beregalov
In-Reply-To: <49EE8855.1080306@oracle.com>
On Wednesday 22 April 2009, Randy Dunlap wrote:
> > Is there maybe a way to force Kconfig to just reject
> > such illegal configs -- neither option set -- rather
> > than trying some how to fix it?
>=20
> Not that I know of. =A0cc-ing Sam.
We could just make the USB_OHCI_HCD_PPC_OF option implicit
and selected only if at least one of USB_OHCI_HCD_PPC_OF_BE
and USB_OHCI_HCD_PPC_OF_LE are set.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 845479f..07e3e25 100644
=2D-- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -161,26 +161,26 @@ config USB_OHCI_HCD_PPC_SOC
Enables support for the USB controller on the MPC52xx or
STB03xxx processor chip. If unsure, say Y.
=20
=2Dconfig USB_OHCI_HCD_PPC_OF
=2D bool "OHCI support for PPC USB controller on OF platform bus"
=2D depends on USB_OHCI_HCD && PPC_OF
=2D default y
=2D ---help---
=2D Enables support for the USB controller PowerPC present on the
=2D OpenFirmware platform bus.
=2D
config USB_OHCI_HCD_PPC_OF_BE
=2D bool "Support big endian HC"
=2D depends on USB_OHCI_HCD_PPC_OF
=2D default y
+ bool "OHCI support for OF platform bus (big endian)"
+ depends on USB_OHCI_HCD && PPC_OF
select USB_OHCI_BIG_ENDIAN_DESC
select USB_OHCI_BIG_ENDIAN_MMIO
+ ---help---
+ Enables support for big-endian USB controllers present on the
+ OpenFirmware platform bus.
=20
config USB_OHCI_HCD_PPC_OF_LE
=2D bool "Support little endian HC"
=2D depends on USB_OHCI_HCD_PPC_OF
=2D default n
+ bool "OHCI support for OF platform bus (little endian)"
+ depends on USB_OHCI_HCD && PPC_OF
select USB_OHCI_LITTLE_ENDIAN
+ ---help---
+ Enables support for little-endian USB controllers present on the
+ OpenFirmware platform bus.
+
+config USB_OHCI_HCD_PPC_OF
+ bool
+ default USB_OHCI_HCD_PPC_OF_BE || USB_OHCI_HCD_PPC_OF_LE
=20
config USB_OHCI_HCD_PCI
bool "OHCI support for PCI-bus USB controllers"
^ permalink raw reply
* Re: [BUILD FAILURE 09/12] Next April 21 : PPC64 randconfig [drivers/staging/comedi/drivers.o]
From: Geert Uytterhoeven @ 2009-04-22 7:43 UTC (permalink / raw)
To: Michael Ellerman
Cc: sachinp, Stephen Rothwell, Greg KH, David A. Schleef,
linux-kernel, Linuxppc-dev, linux-next, subrata,
Alexander Beregalov
In-Reply-To: <1240358910.6571.6.camel@localhost>
On Wed, 22 Apr 2009, Michael Ellerman wrote:
> On Wed, 2009-04-22 at 00:23 +0530, Subrata Modak wrote:
> > Reported this error on 14th April:
> > http://lkml.org/lkml/2009/4/14/488,
> >
> > CC [M] drivers/staging/comedi/drivers.o
> > drivers/staging/comedi/drivers.c: In function ‘comedi_buf_alloc’:
> > drivers/staging/comedi/drivers.c:496: error: ‘PAGE_KERNEL_NOCACHE’
> > undeclared (first use in this function)
> > drivers/staging/comedi/drivers.c:496: error: (Each undeclared identifier
> > is reported only once
> > drivers/staging/comedi/drivers.c:496: error: for each function it
> > appears in.)
> > make[3]: *** [drivers/staging/comedi/drivers.o] Error 1
> > make[2]: *** [drivers/staging/comedi] Error 2
> > make[1]: *** [drivers/staging] Error 2
> > make: *** [drivers] Error 2
>
> Subrata, unless someone says otherwise, please do not send randconfig
> failures for drivers in staging - those drivers have bigger problems
> than randconfig failures.
Indeed, in particular this one http://lkml.org/lkml/2009/3/9/349.
> To avoid them, do this:
>
> # make randconfig
> # sed -i -e 's/^\(CONFIG_STAGING\)=y/# \1 is not set/' .config
^^^^^^^^^^^^^^^
Recently I discovered that `n' actually works, too!
> # make oldconfig
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH] [net, 83xx] ucc_geth.c: Fix upsmr setting in RMII mode
From: David Miller @ 2009-04-22 7:46 UTC (permalink / raw)
To: leoli; +Cc: gridish, netdev, hs, linuxppc-dev
In-Reply-To: <2a27d3730904210351s870f015gb896a4b874b3024b@mail.gmail.com>
From: Li Yang <leoli@freescale.com>
Date: Tue, 21 Apr 2009 18:51:11 +0800
> On Tue, Apr 21, 2009 at 4:36 PM, Heiko Schocher <hs@denx.de> wrote:
>> If using the UCC on a MPC8360 in RMII mode, don;t set
>> UCC_GETH_UPSMR_RPM bit in the upsmr register.
>>
>> Signed-off-by: Heiko Schocher <hs@denx.de>
>
> Acked-by: Li Yang <leoli@freescale.com>
Applied, thanks.
^ permalink raw reply
* [MTD] ofpart: Partitions at same address cannot have the same name
From: Ricardo Ribalda Delgado @ 2009-04-22 8:05 UTC (permalink / raw)
To: linuxppc-dev, ben, David.Woodhouse, linuxppc-embedded
Cc: Ricardo Ribalda Delgado
Sometimes, an special partition is included in the device tree including all the
partitions. Like in:
partition@ff000000 {
reg = < 0x000000 0x800000 >;
label = "Root File System";
};
partition@ff800000 {
reg = < 0x800000 0x1a0000 >;
label = "Bitstream";
};
...
partitionAll@ff000000 {
reg = < 0x000000 0x1000000 >;
label = "Full FLASH";
};
Because two nodes of a device tree cannot have the same name, but all the
partitions must be named "partition", this special partition is invalid.
This patch makes ofpart.c only check for the firt part of the name, and
ignore the rest, allowing this special partition.
---
The extra partition is quite useful while formating the full firmware from linux
drivers/mtd/ofpart.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 3e164f0..0af3b07 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -48,7 +48,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
/* check if this is a partition node */
partname = of_get_property(pp, "name", &len);
- if (strcmp(partname, "partition") != 0) {
+ if (strncmp(partname, "partition", strlen("partition")-1)
+ != 0) {
nr_parts--;
continue;
}
--
1.6.2.4
^ permalink raw reply related
* freeze when reading a PCI bridge register
From: Nicolas Lavocat @ 2009-04-22 8:04 UTC (permalink / raw)
To: linuxppc-dev
Hi everybody!
I' am trying to configure a PCI bridge on a private board, with a
powerpc . In a first time, I tried to get informations about PCI
devices, in order to be sure that my read and write methods work (
using 2 configuration registers, like on an x86 architecture.) . 2
configuration registers are used, for example we write an encoded
address (it is a request to a PCI device) in the first and the answer of
the PCI device can be read in the second register (it is a configuration
cycle)
Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
For example, the code used under u-boot:
volatile u32* addr;
u32 vendor_device_ID;
puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
addr=CFG_ADDR_PCI1;
*addr=0x80007800;
addr= CFG_DATA_PCI1;
vendor_device_ID= *addr;
printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x \n" ,vendor_device_ID);
Therefore, when I do the same thing under Linux, the system crash when I
try to read the second register...
Linux is frozen, and there is no error message.
Under Linux, I made an ioremap before use the registers and access to
these registers thanks to functions "in_be32" and "out_be32".
I tried with different endianness to avoid an error of this type.
If I understand, the main difference between u-boot and Linux (about
registers access) is the activation of the MMU.
So I thought that problem could come from it.
I think the problem could came from the configuration of DBAT and IBATS
registers of the MMU, but I didn't found any information about the MMU
configuration under Linux.
So after this novel, I have some questions:
-Is the MMU configuration generic under Linux?
-Does somebody think that the problem doesn't come from MMU?
-How does work ioremap? Is it a fully software function, or does it
speaks to MMU to get the effective address from physical address?
-Does somebody have an idea, or a documentation about MMU configuration
under linux?
-Do you think that my MMU is under the control of an evil spirit? ^^
thank you for your help
Nicolas Lavocat
^ permalink raw reply
* Re: [PATCH v6] spi: Add PPC4xx SPI driver
From: Stefan Roese @ 2009-04-22 8:29 UTC (permalink / raw)
To: David Brownell; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <200904212236.12904.david-b@pacbell.net>
On Wednesday 22 April 2009, David Brownell wrote:
> On Thursday 08 January 2009, Stefan Roese wrote:
> > This adds a SPI driver for the SPI controller found in the IBM/AMCC
> > 4xx PowerPC's.
>
> Note that given some patches now in the mm tree, this needs
> something like the appended fixup. Some common code has now
> moved into the spi core.
So would you accept the driver for 2.6.31 merge with your suggested change
below? If yes, I'll generate a 7th version.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* RE: freeze when reading a PCI bridge register
From: Liu Dave-R63238 @ 2009-04-22 8:30 UTC (permalink / raw)
To: Nicolas Lavocat, linuxppc-dev
In-Reply-To: <49EECF8D.9000808@fr.thalesgroup.com>
> I' am trying to configure a PCI bridge on a private board, with a=20
> powerpc . In a first time, I tried to get informations about PCI=20
> devices, in order to be sure that my read and write methods work (=20
> using 2 configuration registers, like on an x86 architecture.) . 2=20
> configuration registers are used, for example we write an encoded=20
> address (it is a request to a PCI device) in the first and=20
> the answer of=20
> the PCI device can be read in the second register (it is a=20
> configuration=20
> cycle)
> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
>=20
> For example, the code used under u-boot:
>=20
> volatile u32* addr;
> u32 vendor_device_ID;
>=20
> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
> addr=3DCFG_ADDR_PCI1;
> *addr=3D0x80007800;
>=20
> addr=3D CFG_DATA_PCI1;
> vendor_device_ID=3D *addr;
> printf("PCI1: PCI1_VENDOR_DEVICE_ID=3D %08x \n" ,vendor_device_ID);
>=20
>=20
> Therefore, when I do the same thing under Linux, the system=20
> crash when I=20
> try to read the second register...
> Linux is frozen, and there is no error message.
> Under Linux, I made an ioremap before use the registers and access to=20
> these registers thanks to functions "in_be32" and "out_be32".
> I tried with different endianness to avoid an error of this type.
>=20
> If I understand, the main difference between u-boot and Linux (about=20
> registers access) is the activation of the MMU.
> So I thought that problem could come from it.=20
> I think the problem could came from the configuration of DBAT=20
> and IBATS=20
> registers of the MMU, but I didn't found any information=20
> about the MMU=20
> configuration under Linux.
> So after this novel, I have some questions:
>=20
> -Is the MMU configuration generic under Linux?
> -Does somebody think that the problem doesn't come from MMU?
> -How does work ioremap? Is it a fully software function, or does it=20
> speaks to MMU to get the effective address from physical address?
> -Does somebody have an idea, or a documentation about MMU=20
> configuration=20
> under linux?
> -Do you think that my MMU is under the control of an evil spirit? ^^
>=20
What is the PowerPC you are using?
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: Nicolas Lavocat @ 2009-04-22 8:31 UTC (permalink / raw)
To: Liu Dave-R63238; +Cc: linuxppc-dev
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928C4DB@zch01exm21.fsl.freescale.net>
[-- Attachment #1: Type: text/html, Size: 2526 bytes --]
^ permalink raw reply
* RE: freeze when reading a PCI bridge register
From: Liu Dave-R63238 @ 2009-04-22 8:33 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: linuxppc-dev
In-Reply-To: <49EED5EB.7050005@fr.thalesgroup.com>
[-- Attachment #1: Type: text/plain, Size: 2655 bytes --]
So the host bridge is important, what is the bridge?
Marvell or Tundra chipset?
________________________________
From: Nicolas Lavocat [mailto:nicolas.lavocat@fr.thalesgroup.com]
Sent: Wednesday, April 22, 2009 4:32 PM
To: Liu Dave-R63238
Cc: linuxppc-dev
Subject: Re: freeze when reading a PCI bridge register
a 7448
Liu Dave-R63238 a écrit :
I' am trying to configure a PCI bridge on a private board, with a
powerpc . In a first time, I tried to get informations about PCI
devices, in order to be sure that my read and write methods work (
using 2 configuration registers, like on an x86 architecture.) . 2
configuration registers are used, for example we write an encoded
address (it is a request to a PCI device) in the first and
the answer of
the PCI device can be read in the second register (it is a
configuration
cycle)
Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
For example, the code used under u-boot:
volatile u32* addr;
u32 vendor_device_ID;
puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
addr=CFG_ADDR_PCI1;
*addr=0x80007800;
addr= CFG_DATA_PCI1;
vendor_device_ID= *addr;
printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x \n" ,vendor_device_ID);
Therefore, when I do the same thing under Linux, the system
crash when I
try to read the second register...
Linux is frozen, and there is no error message.
Under Linux, I made an ioremap before use the registers and access to
these registers thanks to functions "in_be32" and "out_be32".
I tried with different endianness to avoid an error of this type.
If I understand, the main difference between u-boot and Linux (about
registers access) is the activation of the MMU.
So I thought that problem could come from it.
I think the problem could came from the configuration of DBAT
and IBATS
registers of the MMU, but I didn't found any information
about the MMU
configuration under Linux.
So after this novel, I have some questions:
-Is the MMU configuration generic under Linux?
-Does somebody think that the problem doesn't come from MMU?
-How does work ioremap? Is it a fully software function, or does it
speaks to MMU to get the effective address from physical address?
-Does somebody have an idea, or a documentation about MMU
configuration
under linux?
-Do you think that my MMU is under the control of an evil spirit? ^^
What is the PowerPC you are using?
[-- Attachment #2: Type: text/html, Size: 3602 bytes --]
^ permalink raw reply
* Re: [PATCH v6] spi: Add PPC4xx SPI driver
From: David Brownell @ 2009-04-22 8:56 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <200904221029.38454.sr@denx.de>
On Wednesday 22 April 2009, Stefan Roese wrote:
> On Wednesday 22 April 2009, David Brownell wrote:
> > On Thursday 08 January 2009, Stefan Roese wrote:
> > > This adds a SPI driver for the SPI controller found in the IBM/AMCC
> > > 4xx PowerPC's.
> >
> > Note that given some patches now in the mm tree, this needs
> > something like the appended fixup. Some common code has now
> > moved into the spi core.
>
> So would you accept the driver for 2.6.31 merge with your suggested change
> below? If yes, I'll generate a 7th version.
Hold on until I send the rest of my review comments; almost done.
Sorry for the delay. Yes, I think a 2.6.31 merge should be doable.
- Dave
>
> Thanks.
>
> Best regards,
> Stefan
>
>
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: Nicolas Lavocat @ 2009-04-22 9:10 UTC (permalink / raw)
To: Liu Dave-R63238, linuxppc-dev
In-Reply-To: <D7CCA83BB0796C49BC0BB53B6AB1208928C4DD@zch01exm21.fsl.freescale.net>
[-- Attachment #1: Type: text/html, Size: 4177 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc
From: Stefan Roscher @ 2009-04-22 9:11 UTC (permalink / raw)
To: Roland Dreier
Cc: Joachim Fenkes, OF-EWG, LKML, LinuxPPC-Dev, Christoph Raisch,
Hoang-Nam Nguyen, Alexander Schmidt1, Stefan Roscher
In-Reply-To: <adaws9dvrkp.fsf@cisco.com>
[-- Attachment #1: Type: text/plain, Size: 2137 bytes --]
Hi Roland,
thanks for the quick review. I was hoping you could apply these changes
for 2.6.30 because this will be the codebase for the next OFED release.
The patch is well tested in HPC environment and we haven't seen any
issues.
Regarding Antons patch you are right. If a user allocates an
unrealistically large queue pair it could happen that kmalloc() is not
able to allocate the memory. In this case we will return ENOMEM to the
user so the kernel will not be affected at all. We plan to add vmalloc()
call in case kmalloc() fails for the next kernel release.
Mit freundlichen Grüßen / Kind regards
Stefan Roscher
eHCA/eHEA Linux Driver Development
IBM Systems &Technology Group, Systems Software Development / FW I/O
Firmware Entwicklung 2
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2015
E-Mail: stefan.roscher@de.ibm.com
-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294
From:
Roland Dreier <rdreier@cisco.com>
To:
Stefan Roscher <ossrosch@linux.vnet.ibm.com>
Cc:
"LinuxPPC-Dev" <linuxppc-dev@ozlabs.org>, LKML
<linux-kernel@vger.kernel.org>, "OF-EWG" <ewg@lists.openfabrics.org>,
Roland Dreier <rolandd@cisco.com>, Joachim Fenkes/Germany/IBM@IBMDE,
Christoph Raisch/Germany/IBM@IBMDE, Alexander Schmidt1/Germany/IBM@IBMDE,
Stefan Roscher/Germany/IBM@IBMDE, Hoang-Nam Nguyen/Germany/IBM@IBMDE
Date:
21.04.2009 19:34
Subject:
Re: [PATCH 1/3] IB/ehca: Replace vmalloc with kmalloc
> + queue->queue_pages = kmalloc(nr_of_pages * sizeof(void
*), GFP_KERNEL);
How big might this buffer be? Any chance of allocation failure due to
memory fragmentation?
- R.
[-- Attachment #2: Type: text/html, Size: 3277 bytes --]
^ permalink raw reply
* Re: INET_LRO as tristate and use from modules
From: David Miller @ 2009-04-22 9:12 UTC (permalink / raw)
To: olof
Cc: sachinp, sfr, themann, netdev, linux-kernel, Linuxppc-dev,
linux-next, subrata
In-Reply-To: <20090421193319.GB20237@lixom.net>
From: Olof Johansson <olof@lixom.net>
Date: Tue, 21 Apr 2009 14:33:19 -0500
> On Wed, Apr 22, 2009 at 12:23:03AM +0530, Subrata Modak wrote:
>> MODPOST 338 modules
>> ERROR: ".lro_receive_skb" [drivers/net/pasemi_mac_driver.ko] undefined!
>> ERROR: ".lro_flush_all" [drivers/net/pasemi_mac_driver.ko] undefined!
>> WARNING: modpost: Found 1 section mismatch(es).
>> To see full details build your kernel with:
>> 'make CONFIG_DEBUG_SECTION_MISMATCH=y'
>> make[1]: *** [__modpost] Error 1
>> make: *** [modules] Error 2
>
> This seems to be a problem with all tristate-capable drivers that use
> LRO (and uses select INET_LRO in their Kconfig): INET_LRO is a tristate
> and can thus be a module. Looks like it needs to be a bool instead?
Yes, making this a bool would be the easiest fix.
By why don't we get the same problem for PHYLIB? It's also
tristate and "select"'d by a whole slew of networking drivers.
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: tiejun.chen @ 2009-04-22 9:21 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: linuxppc-dev
In-Reply-To: <49EECF8D.9000808@fr.thalesgroup.com>
Nicolas Lavocat wrote:
> Hi everybody!
>
> I' am trying to configure a PCI bridge on a private board, with a
> powerpc . In a first time, I tried to get informations about PCI
> devices, in order to be sure that my read and write methods work (
> using 2 configuration registers, like on an x86 architecture.) . 2
> configuration registers are used, for example we write an encoded
> address (it is a request to a PCI device) in the first and the answer of
> the PCI device can be read in the second register (it is a configuration
> cycle)
> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
>
> For example, the code used under u-boot:
>
> volatile u32* addr;
> u32 vendor_device_ID;
>
> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
> addr=CFG_ADDR_PCI1;
> *addr=0x80007800;
>
> addr= CFG_DATA_PCI1;
> vendor_device_ID= *addr;
> printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x \n" ,vendor_device_ID);
>
>
> Therefore, when I do the same thing under Linux, the system crash when I
> try to read the second register...
> Linux is frozen, and there is no error message.
> Under Linux, I made an ioremap before use the registers and access to
> these registers thanks to functions "in_be32" and "out_be32".
> I tried with different endianness to avoid an error of this type.
>
> If I understand, the main difference between u-boot and Linux (about
> registers access) is the activation of the MMU.
> So I thought that problem could come from it. I think the problem could
> came from the configuration of DBAT and IBATS registers of the MMU, but
> I didn't found any information about the MMU configuration under Linux.
> So after this novel, I have some questions:
>
> -Is the MMU configuration generic under Linux?
> -Does somebody think that the problem doesn't come from MMU?
> -How does work ioremap? Is it a fully software function, or does it
> speaks to MMU to get the effective address from physical address?
> -Does somebody have an idea, or a documentation about MMU configuration
> under linux?
> -Do you think that my MMU is under the control of an evil spirit? ^^
>
> thank you for your help
>
Looks you want to re-configure the PCI bridge again?
If so you really should do the private fixup function via some kernel API,
DECLARE_PCI_FIXUP_XXXX. It's not reasonable to re-configure PCI bridge after PCI
sub-system initial process is completed by kernel.
Best Regards
Tiejun
> Nicolas Lavocat
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [MTD] ofpart: Partitions at same address cannot have the same name
From: Peter Korsgaard @ 2009-04-22 9:24 UTC (permalink / raw)
To: Ricardo Ribalda Delgado; +Cc: linuxppc-dev, David.Woodhouse, linuxppc-embedded
In-Reply-To: <1240387541-16594-1-git-send-email-ricardo.ribalda@uam.es>
>>>>> "Ricardo" == Ricardo Ribalda Delgado <ricardo.ribalda@uam.es> writes:
Hi,
Ricardo> Sometimes, an special partition is included in the device
Ricardo> tree including all the partitions. Like in:
Ricardo> drivers/mtd/ofpart.c | 3 ++-
Ricardo> 1 files changed, 2 insertions(+), 1 deletions(-)
Ricardo> diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
Ricardo> index 3e164f0..0af3b07 100644
Ricardo> --- a/drivers/mtd/ofpart.c
Ricardo> +++ b/drivers/mtd/ofpart.c
Ricardo> @@ -48,7 +48,8 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
Ricardo> /* check if this is a partition node */
Ricardo> partname = of_get_property(pp, "name", &len);
Ricardo> - if (strcmp(partname, "partition") != 0) {
Ricardo> + if (strncmp(partname, "partition", strlen("partition")-1)
Why strlen() - 1 ?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: Nicolas Lavocat @ 2009-04-22 9:26 UTC (permalink / raw)
To: tiejun.chen; +Cc: linuxppc-dev
In-Reply-To: <49EEE18C.5000805@windriver.com>
[-- Attachment #1: Type: text/html, Size: 3861 bytes --]
^ permalink raw reply
* Re: [BUILD FAILURE 05/12] Next April 21 : PPC64 randconfig [drivers/macintosh/mediabay.o]
From: Bartlomiej Zolnierkiewicz @ 2009-04-22 9:34 UTC (permalink / raw)
To: Paul Mackerras
Cc: sachinp, Stephen Rothwell, Adrian Bunk, linux-kernel,
Stefan Bader, Linuxppc-dev, linux-next, Marcelo Tosatti, subrata,
Alexander Beregalov
In-Reply-To: <18926.38431.910952.630575@cargo.ozlabs.ibm.com>
On Wednesday 22 April 2009 05:59:27 Paul Mackerras wrote:
> Bartlomiej Zolnierkiewicz writes:
>
> > mediabay shouldn't include <linux/ide.h> unconditionally so
> > remove the superfluous include from mediabay.c (<asm/mediabay.h>
> > will pull <linux/ide.h> in for CONFIG_BLK_DEV_IDE_PMAC=y).
>
> I don't like relying on second-hand imports like that. I prefer the
> previous patch, that made mediabay depend on CONFIG_BLOCK.
I missed it somehow...
OK, I found it now and it should fix the problem as well.
> BTW, if including <linux/ide.h> causes an error when CONFIG_BLOCK=n,
> then there is a bug in <linux/ide.h>, IMO.
<linux/ide.h> is for drivers/ide only. mediabay lacks proper abstraction
layer and is probably the only abuser left.
Besides being a build fix my patch is a right step in cleaning this mess
so I'm going to apply it through ide tree.
Thanks,
Bart
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: tiejun.chen @ 2009-04-22 9:45 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: linuxppc-dev
In-Reply-To: <49EEE2C2.7@fr.thalesgroup.com>
Nicolas Lavocat wrote:
> In fact, because system froze, I wanted to know where was the problem, so, step
> by step, I removed operations, until try to read this register, basic operation
> when a PCI device is used. This register can be read with JTAG, and under uboot,
> so I think that it is not a PCI problem..
>
I agreed this is not a PCI hardware problem as you said. But you want to
read/write PCI device on Linux you have to work under the Linux rules. If you
remove your PCI operation PCI works well I think MMU should be good as well.
BTW, you will make life easier for others if you can attach your crash log.
Best Regards
Tiejun
> Nicolas Lavocat
>
> tiejun.chen a écrit :
>> Nicolas Lavocat wrote:
>>
>>> Hi everybody!
>>>
>>> I' am trying to configure a PCI bridge on a private board, with a
>>> powerpc . In a first time, I tried to get informations about PCI
>>> devices, in order to be sure that my read and write methods work (
>>> using 2 configuration registers, like on an x86 architecture.) . 2
>>> configuration registers are used, for example we write an encoded
>>> address (it is a request to a PCI device) in the first and the answer of
>>> the PCI device can be read in the second register (it is a configuration
>>> cycle)
>>> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
>>>
>>> For example, the code used under u-boot:
>>>
>>> volatile u32* addr;
>>> u32 vendor_device_ID;
>>>
>>> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
>>> addr=CFG_ADDR_PCI1;
>>> *addr=0x80007800;
>>>
>>> addr= CFG_DATA_PCI1;
>>> vendor_device_ID= *addr;
>>> printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x \n" ,vendor_device_ID);
>>>
>>>
>>> Therefore, when I do the same thing under Linux, the system crash when I
>>> try to read the second register...
>>> Linux is frozen, and there is no error message.
>>> Under Linux, I made an ioremap before use the registers and access to
>>> these registers thanks to functions "in_be32" and "out_be32".
>>> I tried with different endianness to avoid an error of this type.
>>>
>>> If I understand, the main difference between u-boot and Linux (about
>>> registers access) is the activation of the MMU.
>>> So I thought that problem could come from it. I think the problem could
>>> came from the configuration of DBAT and IBATS registers of the MMU, but
>>> I didn't found any information about the MMU configuration under Linux.
>>> So after this novel, I have some questions:
>>>
>>> -Is the MMU configuration generic under Linux?
>>> -Does somebody think that the problem doesn't come from MMU?
>>> -How does work ioremap? Is it a fully software function, or does it
>>> speaks to MMU to get the effective address from physical address?
>>> -Does somebody have an idea, or a documentation about MMU configuration
>>> under linux?
>>> -Do you think that my MMU is under the control of an evil spirit? ^^
>>>
>>> thank you for your help
>>>
>>>
>>
>> Looks you want to re-configure the PCI bridge again?
>>
>> If so you really should do the private fixup function via some kernel API,
>> DECLARE_PCI_FIXUP_XXXX. It's not reasonable to re-configure PCI bridge after PCI
>> sub-system initial process is completed by kernel.
>>
>> Best Regards
>> Tiejun
>>
>>
>>> Nicolas Lavocat
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>
>>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>
^ permalink raw reply
* Re: [PATCH] keywest: Convert to new-style i2c driver
From: Paul Mackerras @ 2009-04-22 9:34 UTC (permalink / raw)
To: Jean Delvare; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <20090421114853.7a9d82c1@hyperion.delvare>
Jean Delvare writes:
> Not removing it now has a high risk of developers continuing to ignore
> the deprecation warnings and adding new legacy drivers, which I then
> must convert to the new model. This never ends.
>
> I know my behavior may seem a bit rude, but apparently this is the only
> way to get things to actually happen. I've been waiting for over a year
> already!
I sympathize, but throwing disruptive changes into Linus' tree when
we're past -rc3 is not the way to solve the problem.
The way to solve the problem is to (a) publish a branch where you put
the stuff you're going to ask Linus to pull in the next merge window,
(b) push a commit there that removes the legacy interfaces, (c) ask
Stephen Rothwell to include that branch in linux-next.
The linux-next tree gets built for a wide range of architectures and
configs, and any breakages get noticed and fixed pretty quickly.
Getting the removal of the legacy interfaces into linux-next will do
more in a week than a year's worth of deprecation warnings. :)
> I don't think the risk is that high, at least not for sound drivers.
> The conversions are fairly easy and if something really went wrong,
> fixing it is a matter of minutes.
We're past -rc3 now. This is not the time for pushing this sort of
change into Linus' tree. Ask Linus if you don't believe me.
> I have converted all remaining drivers by now:
> http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted
> It's really only a matter of getting them tested in time now. Given
> that most drivers are powermac ones, what I really need here is
> powermac users/maintainers to test my patches and report success or
> failure.
OK, but please work in your next branch and linux-next, not Linus'
tree.
Paul.
^ permalink raw reply
* Re: freeze when reading a PCI bridge register
From: Gabriel Paubert @ 2009-04-22 11:03 UTC (permalink / raw)
To: Nicolas Lavocat; +Cc: linuxppc-dev
In-Reply-To: <49EECF8D.9000808@fr.thalesgroup.com>
On Wed, Apr 22, 2009 at 10:04:29AM +0200, Nicolas Lavocat wrote:
> Hi everybody!
>
> I' am trying to configure a PCI bridge on a private board, with a
> powerpc . In a first time, I tried to get informations about PCI
> devices, in order to be sure that my read and write methods work (
> using 2 configuration registers, like on an x86 architecture.) . 2
> configuration registers are used, for example we write an encoded
> address (it is a request to a PCI device) in the first and the answer of
> the PCI device can be read in the second register (it is a configuration
> cycle)
> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
JTAG is probably a completely different hardware path, so it
does not really count. uboot testing is ok.
>
> For example, the code used under u-boot:
>
> volatile u32* addr;
> u32 vendor_device_ID;
>
> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
> addr=CFG_ADDR_PCI1;
> *addr=0x80007800;
>
> addr= CFG_DATA_PCI1;
> vendor_device_ID= *addr;
> printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x \n" ,vendor_device_ID);
2 possibilities:
- your I/O is not marked uncacheable (should be with ioremap)
- the PPC is reordering and issuing the read before the write,
you should use accessors. A simple test is inserting
an asm volatile("eieio") before the read.
About your other mails, please avoid HTML mail.
Gabriel
^ permalink raw reply
* Re: [PATCH] keywest: Convert to new-style i2c driver
From: Jean Delvare @ 2009-04-22 12:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Takashi Iwai, linuxppc-dev, alsa-devel
In-Reply-To: <18926.58544.374626.696097@cargo.ozlabs.ibm.com>
Hi Paul,
On Wed, 22 Apr 2009 19:34:40 +1000, Paul Mackerras wrote:
> Jean Delvare writes:
>
> > Not removing it now has a high risk of developers continuing to ignore
> > the deprecation warnings and adding new legacy drivers, which I then
> > must convert to the new model. This never ends.
> >
> > I know my behavior may seem a bit rude, but apparently this is the only
> > way to get things to actually happen. I've been waiting for over a year
> > already!
>
> I sympathize, but throwing disruptive changes into Linus' tree when
> we're past -rc3 is not the way to solve the problem.
We're past -rc3 because people discuss instead of testing my patches.
Otherwise everything would be merged already.
And really, these changes (sound drivers) don't qualify as disruptive.
You might argue about the thermal management driver changes if you
want. But sound drivers, nothing bad will happen if they accidentally
break.
> The way to solve the problem is to (a) publish a branch where you put
> the stuff you're going to ask Linus to pull in the next merge window,
> (b) push a commit there that removes the legacy interfaces, (c) ask
> Stephen Rothwell to include that branch in linux-next.
>
> The linux-next tree gets built for a wide range of architectures and
> configs, and any breakages get noticed and fixed pretty quickly.
> Getting the removal of the legacy interfaces into linux-next will do
> more in a week than a year's worth of deprecation warnings. :)
What do you think, that I don't know about linux-next? My i2c tree is
already there. It has been since linux-next exists.
But linux-next will only build-test the code. That I have already done,
so it really doesn't buy my anything. Developers (including me) don't
look at warnings in linux-next, and I don't think linux-next gets a lot
of testing.
Also, I can't push all untested patches to linux-next. In particular
the 4 patches that touch thermal management on powermac, need to be
tested successfully by at least one person before I can push them. You
did test the therm_pm72 patch, and I thank you for that, so that one is
in linux-next, but the other 3 ones need testing.
So, really, you're trying to solve the wrong problem. Whether the
patches go to Linus now or in the next merge window, doesn't really
matter. What matters is that the patches can't go anywhere before they
have been tested. So, can the powerpc people please test my
patches? You (powerpc developers, not you Paul in particular) didn't
pay attention to the deprecation warnings. I did warn Ben that this
would become a problem during the Kernel Summit last year in Portland
though, but apparently it did not help. I would expect that you at
least help me with testing once I have done all the conversion work.
Out of the 10 remaining legacy i2c drivers, 9 are powerpc drivers!
> > I don't think the risk is that high, at least not for sound drivers.
> > The conversions are fairly easy and if something really went wrong,
> > fixing it is a matter of minutes.
>
> We're past -rc3 now. This is not the time for pushing this sort of
> change into Linus' tree. Ask Linus if you don't believe me.
And 2.6.31 isn't the kernel to remove an interface which was scheduled
for removal in 2.6.29 and then 2.6.30 and which is blocking the
development of features people need badly. One of these two events will
happen still. The real world isn't as perfect as we'd like.
So, once again, can powermac developers/users please test my patches?
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] therm_adt746x: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-22 12:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090416225927.4254efc5@hyperion.delvare>
On Thu, 16 Apr 2009 22:59:27 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> therm_adt746x driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> Can someone please test this patch for me? I could only build-test it.
>
> Remember that you need this patch applied:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0
Any tester for this patch, please?
>
> Thanks.
>
> drivers/macintosh/therm_adt746x.c | 84 ++++++++++++++++++-------------------
> 1 file changed, 42 insertions(+), 42 deletions(-)
>
> --- linux-2.6.30-rc2.orig/drivers/macintosh/therm_adt746x.c 2009-04-16 21:06:31.000000000 +0200
> +++ linux-2.6.30-rc2/drivers/macintosh/therm_adt746x.c 2009-04-16 21:37:05.000000000 +0200
> @@ -71,7 +71,7 @@ MODULE_PARM_DESC(verbose,"Verbose log op
> "(default 0)");
>
> struct thermostat {
> - struct i2c_client clt;
> + struct i2c_client *clt;
> u8 temps[3];
> u8 cached_temp[3];
> u8 initial_limits[3];
> @@ -86,9 +86,6 @@ static struct of_device * of_dev;
> static struct thermostat* thermostat;
> static struct task_struct *thread_therm = NULL;
>
> -static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
> - int busno);
> -
> static void write_both_fan_speed(struct thermostat *th, int speed);
> static void write_fan_speed(struct thermostat *th, int speed, int fan);
>
> @@ -100,7 +97,7 @@ write_reg(struct thermostat* th, int reg
>
> tmp[0] = reg;
> tmp[1] = data;
> - rc = i2c_master_send(&th->clt, (const char *)tmp, 2);
> + rc = i2c_master_send(th->clt, (const char *)tmp, 2);
> if (rc < 0)
> return rc;
> if (rc != 2)
> @@ -115,12 +112,12 @@ read_reg(struct thermostat* th, int reg)
> int rc;
>
> reg_addr = (u8)reg;
> - rc = i2c_master_send(&th->clt, ®_addr, 1);
> + rc = i2c_master_send(th->clt, ®_addr, 1);
> if (rc < 0)
> return rc;
> if (rc != 1)
> return -ENODEV;
> - rc = i2c_master_recv(&th->clt, (char *)&data, 1);
> + rc = i2c_master_recv(th->clt, (char *)&data, 1);
> if (rc < 0)
> return rc;
> return data;
> @@ -130,26 +127,36 @@ static int
> attach_thermostat(struct i2c_adapter *adapter)
> {
> unsigned long bus_no;
> + struct i2c_board_info info;
> + struct i2c_client *client;
>
> if (strncmp(adapter->name, "uni-n", 5))
> return -ENODEV;
> bus_no = simple_strtoul(adapter->name + 6, NULL, 10);
> if (bus_no != therm_bus)
> return -ENODEV;
> - return attach_one_thermostat(adapter, therm_address, bus_no);
> +
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + strlcpy(info.type, "therm_adt746x", I2C_NAME_SIZE);
> + info.addr = therm_address;
> + client = i2c_new_device(adapter, &info);
> + if (!client)
> + return -ENODEV;
> +
> + /*
> + * Let i2c-core delete that device on driver removal.
> + * This is safe because i2c-core holds the core_lock mutex for us.
> + */
> + list_add_tail(&client->detected, &client->driver->clients);
> + return 0;
> }
>
> static int
> -detach_thermostat(struct i2c_adapter *adapter)
> +remove_thermostat(struct i2c_client *client)
> {
> - struct thermostat* th;
> + struct thermostat *th = i2c_get_clientdata(client);
> int i;
>
> - if (thermostat == NULL)
> - return 0;
> -
> - th = thermostat;
> -
> if (thread_therm != NULL) {
> kthread_stop(thread_therm);
> }
> @@ -165,8 +172,6 @@ detach_thermostat(struct i2c_adapter *ad
>
> write_both_fan_speed(th, -1);
>
> - i2c_detach_client(&th->clt);
> -
> thermostat = NULL;
>
> kfree(th);
> @@ -174,14 +179,6 @@ detach_thermostat(struct i2c_adapter *ad
> return 0;
> }
>
> -static struct i2c_driver thermostat_driver = {
> - .driver = {
> - .name = "therm_adt746x",
> - },
> - .attach_adapter = attach_thermostat,
> - .detach_adapter = detach_thermostat,
> -};
> -
> static int read_fan_speed(struct thermostat *th, u8 addr)
> {
> u8 tmp[2];
> @@ -369,8 +366,8 @@ static void set_limit(struct thermostat
> th->limits[i] = default_limits_local[i] + limit_adjust;
> }
>
> -static int attach_one_thermostat(struct i2c_adapter *adapter, int addr,
> - int busno)
> +static int probe_thermostat(struct i2c_client *client,
> + const struct i2c_device_id *id)
> {
> struct thermostat* th;
> int rc;
> @@ -383,16 +380,12 @@ static int attach_one_thermostat(struct
> if (!th)
> return -ENOMEM;
>
> - th->clt.addr = addr;
> - th->clt.adapter = adapter;
> - th->clt.driver = &thermostat_driver;
> - strcpy(th->clt.name, "thermostat");
> + i2c_set_clientdata(client, th);
> + th->clt = client;
>
> rc = read_reg(th, 0);
> if (rc < 0) {
> - printk(KERN_ERR "adt746x: Thermostat failed to read config "
> - "from bus %d !\n",
> - busno);
> + dev_err(&client->dev, "Thermostat failed to read config!\n");
> kfree(th);
> return -ENODEV;
> }
> @@ -421,14 +414,6 @@ static int attach_one_thermostat(struct
>
> thermostat = th;
>
> - if (i2c_attach_client(&th->clt)) {
> - printk(KERN_INFO "adt746x: Thermostat failed to attach "
> - "client !\n");
> - thermostat = NULL;
> - kfree(th);
> - return -ENODEV;
> - }
> -
> /* be sure to really write fan speed the first time */
> th->last_speed[0] = -2;
> th->last_speed[1] = -2;
> @@ -454,6 +439,21 @@ static int attach_one_thermostat(struct
> return 0;
> }
>
> +static const struct i2c_device_id therm_adt746x_id[] = {
> + { "therm_adt746x", 0 },
> + { }
> +};
> +
> +static struct i2c_driver thermostat_driver = {
> + .driver = {
> + .name = "therm_adt746x",
> + },
> + .attach_adapter = attach_thermostat,
> + .probe = probe_thermostat,
> + .remove = remove_thermostat,
> + .id_table = therm_adt746x_id,
> +};
> +
> /*
> * Now, unfortunately, sysfs doesn't give us a nice void * we could
> * pass around to the attribute functions, so we don't really have
>
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] therm_windtunnel: Convert to a new-style i2c driver
From: Jean Delvare @ 2009-04-22 12:10 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090416230101.37f3e84f@hyperion.delvare>
On Thu, 16 Apr 2009 23:01:01 +0200, Jean Delvare wrote:
> The legacy i2c binding model is going away soon, so convert the ppc
> therm_windtunnel driver to the new model or it will break.
>
> Signed-off-by: Jean Delvare <khali@linux-fr.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> ---
> Can someone please test this patch for me? I could only build-test it.
>
> Remember that you need this patch applied:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=935298696f469c0e07c73be687bd055878074ce0
Any tester for this patch, please?
>
> Thanks.
>
> drivers/macintosh/therm_windtunnel.c | 126 ++++++++++++++++------------------
> 1 file changed, 60 insertions(+), 66 deletions(-)
>
> --- linux-2.6.30-rc2.orig/drivers/macintosh/therm_windtunnel.c 2009-03-24 13:40:47.000000000 +0100
> +++ linux-2.6.30-rc2/drivers/macintosh/therm_windtunnel.c 2009-04-16 22:56:39.000000000 +0200
> @@ -48,16 +48,6 @@
>
> #define LOG_TEMP 0 /* continously log temperature */
>
> -static int do_probe( struct i2c_adapter *adapter, int addr, int kind);
> -
> -/* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
> -static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4b,
> - 0x4c, 0x4d, 0x4e, 0x4f,
> - 0x2c, 0x2d, 0x2e, 0x2f,
> - I2C_CLIENT_END };
> -
> -I2C_CLIENT_INSMOD;
> -
> static struct {
> volatile int running;
> struct task_struct *poll_task;
> @@ -315,53 +305,54 @@ static int control_loop(void *dummy)
> static int
> do_attach( struct i2c_adapter *adapter )
> {
> - int ret = 0;
> + /* scan 0x48-0x4f (DS1775) and 0x2c-2x2f (ADM1030) */
> + static const unsigned short scan_ds1775[] = {
> + 0x48, 0x49, 0x4a, 0x4b, 0x4c, 0x4d, 0x4e, 0x4f,
> + I2C_CLIENT_END
> + };
> + static const unsigned short scan_adm1030[] = {
> + 0x2c, 0x2d, 0x2e, 0x2f,
> + I2C_CLIENT_END
> + };
>
> if( strncmp(adapter->name, "uni-n", 5) )
> return 0;
>
> if( !x.running ) {
> - ret = i2c_probe( adapter, &addr_data, &do_probe );
> + struct i2c_board_info info;
> +
> + memset(&info, 0, sizeof(struct i2c_board_info));
> + strlcpy(info.type, "therm_ds1775", I2C_NAME_SIZE);
> + i2c_new_probed_device(adapter, &info, scan_ds1775);
> +
> + strlcpy(info.type, "therm_adm1030", I2C_NAME_SIZE);
> + i2c_new_probed_device(adapter, &info, scan_adm1030);
> +
> if( x.thermostat && x.fan ) {
> x.running = 1;
> x.poll_task = kthread_run(control_loop, NULL, "g4fand");
> }
> }
> - return ret;
> + return 0;
> }
>
> static int
> -do_detach( struct i2c_client *client )
> +do_remove(struct i2c_client *client)
> {
> - int err;
> -
> - if( (err=i2c_detach_client(client)) )
> - printk(KERN_ERR "failed to detach thermostat client\n");
> - else {
> - if( x.running ) {
> - x.running = 0;
> - kthread_stop(x.poll_task);
> - x.poll_task = NULL;
> - }
> - if( client == x.thermostat )
> - x.thermostat = NULL;
> - else if( client == x.fan )
> - x.fan = NULL;
> - else {
> - printk(KERN_ERR "g4fan: bad client\n");
> - }
> - kfree( client );
> + if (x.running) {
> + x.running = 0;
> + kthread_stop(x.poll_task);
> + x.poll_task = NULL;
> }
> - return err;
> -}
> + if (client == x.thermostat)
> + x.thermostat = NULL;
> + else if (client == x.fan)
> + x.fan = NULL;
> + else
> + printk(KERN_ERR "g4fan: bad client\n");
>
> -static struct i2c_driver g4fan_driver = {
> - .driver = {
> - .name = "therm_windtunnel",
> - },
> - .attach_adapter = do_attach,
> - .detach_client = do_detach,
> -};
> + return 0;
> +}
>
> static int
> attach_fan( struct i2c_client *cl )
> @@ -374,13 +365,8 @@ attach_fan( struct i2c_client *cl )
> goto out;
> printk("ADM1030 fan controller [@%02x]\n", cl->addr );
>
> - strlcpy( cl->name, "ADM1030 fan controller", sizeof(cl->name) );
> -
> - if( !i2c_attach_client(cl) )
> - x.fan = cl;
> + x.fan = cl;
> out:
> - if( cl != x.fan )
> - kfree( cl );
> return 0;
> }
>
> @@ -412,39 +398,47 @@ attach_thermostat( struct i2c_client *cl
> x.temp = temp;
> x.overheat_temp = os_temp;
> x.overheat_hyst = hyst_temp;
> -
> - strlcpy( cl->name, "DS1775 thermostat", sizeof(cl->name) );
> -
> - if( !i2c_attach_client(cl) )
> - x.thermostat = cl;
> + x.thermostat = cl;
> out:
> - if( cl != x.thermostat )
> - kfree( cl );
> return 0;
> }
>
> +enum chip { ds1775, adm1030 };
> +
> +static const struct i2c_device_id therm_windtunnel_id[] = {
> + { "therm_ds1775", ds1775 },
> + { "therm_adm1030", adm1030 },
> + { }
> +};
> +
> static int
> -do_probe( struct i2c_adapter *adapter, int addr, int kind )
> +do_probe(struct i2c_client *cl, const struct i2c_device_id *id)
> {
> - struct i2c_client *cl;
> + struct i2c_adapter *adapter = cl->adapter;
>
> if( !i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA
> | I2C_FUNC_SMBUS_WRITE_BYTE) )
> return 0;
>
> - if( !(cl=kzalloc(sizeof(*cl), GFP_KERNEL)) )
> - return -ENOMEM;
> -
> - cl->addr = addr;
> - cl->adapter = adapter;
> - cl->driver = &g4fan_driver;
> - cl->flags = 0;
> -
> - if( addr < 0x48 )
> + switch (id->driver_data) {
> + case adm1030:
> return attach_fan( cl );
> - return attach_thermostat( cl );
> + case ds1775:
> + return attach_thermostat(cl);
> + }
> + return 0;
> }
>
> +static struct i2c_driver g4fan_driver = {
> + .driver = {
> + .name = "therm_windtunnel",
> + },
> + .attach_adapter = do_attach,
> + .probe = do_probe,
> + .remove = do_remove,
> + .id_table = therm_windtunnel_id,
> +};
> +
>
> /************************************************************************/
> /* initialization / cleanup */
>
>
--
Jean Delvare
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox