* [PATCH 2/2] arch/powerpc/kernel/irq.c: Add of_node_put to avoid memory leak
From: Julia Lawall @ 2010-09-04 10:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Paul Mackerras, kernel-janitors, linuxppc-dev, linux-kernel
In this case, a device_node structure is stored in another structure that
is then freed without first decrementing the reference count of the
device_node structure.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression x;
identifier f;
position p1,p2;
@@
x@p1->f = \(of_find_node_by_path\|of_find_node_by_name\|of_find_node_by_phandle\|of_get_parent\|of_get_next_parent\|of_get_next_child\|of_find_compatible_node\|of_match_node\|of_find_node_by_type\|of_find_node_with_property\|of_find_matching_node\|of_parse_phandle\|of_node_get\)(...);
... when != of_node_put(x)
kfree@p2(x)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
cocci.print_main("call",p1)
cocci.print_secs("free",p2)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
arch/powerpc/kernel/irq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 4a65386..0a5bbe5 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -587,8 +587,10 @@ struct irq_host *irq_alloc_host(struct device_node *of_node,
* this will be fixed once slab is made available early
* instead of the current cruft
*/
- if (mem_init_done)
+ if (mem_init_done) {
+ of_node_put(host->of_node);
kfree(host);
+ }
return NULL;
}
irq_map[0].host = host;
^ permalink raw reply related
* [PATCH 1/2] drivers/net/fs_enet/fs_enet-main.c: Add of_node_put to avoid memory leak
From: Julia Lawall @ 2010-09-04 10:12 UTC (permalink / raw)
To: Pantelis Antoniou
Cc: netdev, devicetree-discuss, kernel-janitors, linux-kernel,
Vitaly Bordug, linuxppc-dev
In this case, a device_node structure is stored in another structure that
is then freed without first decrementing the reference count of the
device_node structure.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@r exists@
expression x;
identifier f;
position p1,p2;
@@
x@p1->f = \(of_find_node_by_path\|of_find_node_by_name\|of_find_node_by_phandle\|of_get_parent\|of_get_next_parent\|of_get_next_child\|of_find_compatible_node\|of_match_node\|of_find_node_by_type\|of_find_node_with_property\|of_find_matching_node\|of_parse_phandle\|of_node_get\)(...);
... when != of_node_put(x)
kfree@p2(x)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
cocci.print_main("call",p1)
cocci.print_secs("free",p2)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/net/fs_enet/fs_enet-main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index d6e3111..d684f18 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -1036,7 +1036,7 @@ static int __devinit fs_enet_probe(struct platform_device *ofdev,
ndev = alloc_etherdev(privsize);
if (!ndev) {
ret = -ENOMEM;
- goto out_free_fpi;
+ goto out_put;
}
SET_NETDEV_DEV(ndev, &ofdev->dev);
@@ -1099,6 +1099,7 @@ out_cleanup_data:
out_free_dev:
free_netdev(ndev);
dev_set_drvdata(&ofdev->dev, NULL);
+out_put:
of_node_put(fpi->phy_node);
out_free_fpi:
kfree(fpi);
^ permalink raw reply related
* Re: [PATCH 1/2] drivers/net/fs_enet/fs_enet-main.c: Add of_node_put to avoid memory leak
From: Wolfram Sang @ 2010-09-04 15:48 UTC (permalink / raw)
To: Julia Lawall
Cc: netdev, devicetree-discuss, kernel-janitors, linux-kernel,
Vitaly Bordug, linuxppc-dev
In-Reply-To: <1283595164-29146-1-git-send-email-julia@diku.dk>
[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]
On Sat, Sep 04, 2010 at 12:12:43PM +0200, Julia Lawall wrote:
> In this case, a device_node structure is stored in another structure that
> is then freed without first decrementing the reference count of the
> device_node structure.
>
> The semantic match that finds this problem is as follows:
> (http://coccinelle.lip6.fr/)
>
> // <smpl>
> @r exists@
> expression x;
> identifier f;
> position p1,p2;
> @@
>
> x@p1->f = \(of_find_node_by_path\|of_find_node_by_name\|of_find_node_by_phandle\|of_get_parent\|of_get_next_parent\|of_get_next_child\|of_find_compatible_node\|of_match_node\|of_find_node_by_type\|of_find_node_with_property\|of_find_matching_node\|of_parse_phandle\|of_node_get\)(...);
> ... when != of_node_put(x)
> kfree@p2(x)
>
> @script:python@
> p1 << r.p1;
> p2 << r.p2;
> @@
> cocci.print_main("call",p1)
> cocci.print_secs("free",p2)
> // </smpl>
>
> Signed-off-by: Julia Lawall <julia@diku.dk>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
>
> ---
> drivers/net/fs_enet/fs_enet-main.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
> index d6e3111..d684f18 100644
> --- a/drivers/net/fs_enet/fs_enet-main.c
> +++ b/drivers/net/fs_enet/fs_enet-main.c
> @@ -1036,7 +1036,7 @@ static int __devinit fs_enet_probe(struct platform_device *ofdev,
> ndev = alloc_etherdev(privsize);
> if (!ndev) {
> ret = -ENOMEM;
> - goto out_free_fpi;
> + goto out_put;
> }
>
> SET_NETDEV_DEV(ndev, &ofdev->dev);
> @@ -1099,6 +1099,7 @@ out_cleanup_data:
> out_free_dev:
> free_netdev(ndev);
> dev_set_drvdata(&ofdev->dev, NULL);
> +out_put:
> of_node_put(fpi->phy_node);
> out_free_fpi:
> kfree(fpi);
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH 4/8] drivers/i2c/busses/i2c-pasemi.c: Fix unsigned return type
From: Julia Lawall @ 2010-09-05 19:00 UTC (permalink / raw)
To: Olof Johansson
Cc: kernel-janitors, linux-kernel, linux-i2c,
Ben Dooks (embedded platforms), Jean Delvare (PC drivers, core),
linuxppc-dev
In-Reply-To: <1283713226-8429-1-git-send-email-julia@diku.dk>
The function has an unsigned return type, but returns a negative constant
to indicate an error condition. The result of calling the function is
always stored in a variable of type (signed) int, and thus unsigned can be
dropped from the return type.
A sematic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@exists@
identifier f;
constant C;
@@
unsigned f(...)
{ <+...
* return -C;
...+> }
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
---
drivers/i2c/busses/i2c-pasemi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-pasemi.c b/drivers/i2c/busses/i2c-pasemi.c
index 4174101..837b8c1 100644
--- a/drivers/i2c/busses/i2c-pasemi.c
+++ b/drivers/i2c/busses/i2c-pasemi.c
@@ -88,7 +88,7 @@ static void pasemi_smb_clear(struct pasemi_smbus *smbus)
reg_write(smbus, REG_SMSTA, status);
}
-static unsigned int pasemi_smb_waitready(struct pasemi_smbus *smbus)
+static int pasemi_smb_waitready(struct pasemi_smbus *smbus)
{
int timeout = 10;
unsigned int status;
^ permalink raw reply related
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Olof Johansson @ 2010-09-05 22:23 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <197d4509c0b1206ce2d686c03701a6b4@mail.gmail.com>
On Fri, Sep 03, 2010 at 01:38:46PM -0700, Tirumala Marri wrote:
> > >APM821xx is Applied Micro Circuits Corporations naming convention for
> > >new line of SoCs.
> >
> > So is it a 440x6 core then? Or what core is inside the SoC?
> [Marri] It is 464 core.
Then the device tree identifier, and the cpu setup functions, etc, should indicate
464, not APM821xx.
Also, why add yet another defconfig? Isn't the eval board similar to
many others and can be supported with just a tweak of some existing
common defconfig instead?
-Olof
^ permalink raw reply
* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-09-06 3:38 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100903112755.GA11847@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMDMsIDIwMTAgMTk6MjggUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzNdW01URF0gUDQwODAvZUxCQzogTWFrZSBGcmVl
c2NhbGUgZWxiYyBpbnRlcnJ1cHQgY29tbW9uDQo+IHRvIGVsYmMgZGV2aWNlcw0KPiANCj4gT24g
RnJpLCBBdWcgMDYsIDIwMTAgYXQgMTA6NTE6MzRBTSArMDgwMCwgUm95IFphbmcgd3JvdGU6DQo+
ID4gRnJvbTogTGFuIENodW5oZS1CMjU4MDYgPGIyNTgwNkBmcmVlc2NhbGUuY29tPg0KPiA+DQo+
ID4gTW92ZSBGcmVlc2NhbGUgZWxiYyBpbnRlcnJ1cHQgZnJvbSBuYW5kIGRpcnZlciB0byBlbGJj
IGRyaXZlci4NCj4gPiBUaGVuIGFsbCBlbGJjIGRldmljZXMgY2FuIHVzZSB0aGUgaW50ZXJydXB0
IGluc3RlYWQgb2YgT05MWSBuYW5kLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogTGFuIENodW5o
ZS1CMjU4MDYgPGIyNTgwNkBmcmVlc2NhbGUuY29tPg0KPiA+IFNpZ25lZC1vZmYtYnk6IFJveSBa
YW5nIDx0aWUtZmVpLnphbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiAtLS0NCj4gPiBzZW5kIHRoZSBw
YXRjaCB0byBsaW51eC1tdGRAbGlzdHMuaW5mcmFkZWFkLm9yZw0KPiA+IGl0IGhhcyBiZWVuIHBv
c3RlZCB0byBsaW51eHBwYy1kZXZAb3psYWJzLm9yZyBhbmQgZG8gbm90IGdldCBhbnkgY29tbWVu
dC4NCj4gPg0KPiA+ICBhcmNoL3Bvd2VycGMvS2NvbmZpZyAgICAgICAgICAgICAgIHwgICAgNyAr
LQ0KPiA+ICBhcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20vZnNsX2xiYy5oIHwgICAzNCArKysrKy0N
Cj4gPiAgYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfbGJjLmMgICAgICB8ICAyNTQgKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrLS0tDQo+IC0tLQ0KPiA+ICAzIGZpbGVzIGNoYW5nZWQsIDI1
MyBpbnNlcnRpb25zKCspLCA0MiBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9h
cmNoL3Bvd2VycGMvS2NvbmZpZyBiL2FyY2gvcG93ZXJwYy9LY29uZmlnDQo+ID4gaW5kZXggMjAz
MWEyOC4uNTE1NWI1MyAxMDA2NDQNCj4gPiAtLS0gYS9hcmNoL3Bvd2VycGMvS2NvbmZpZw0KPiA+
ICsrKyBiL2FyY2gvcG93ZXJwYy9LY29uZmlnDQo+ID4gQEAgLTcwMyw5ICs3MDMsMTIgQEAgY29u
ZmlnIDR4eF9TT0MNCj4gPiAgCWJvb2wNCj4gPg0KPiA+ICBjb25maWcgRlNMX0xCQw0KPiA+IC0J
Ym9vbA0KPiA+ICsJYm9vbCAiRnJlZXNjYWxlIExvY2FsIEJ1cyBzdXBwb3J0Ig0KPiA+ICsJZGVw
ZW5kcyBvbiBGU0xfU09DDQo+ID4gIAloZWxwDQo+ID4gLQkgIEZyZWVzY2FsZSBMb2NhbGJ1cyBz
dXBwb3J0DQo+ID4gKwkgIEVuYWJsZXMgcmVwb3J0aW5nIG9mIGVycm9ycyBmcm9tIHRoZSBGcmVl
c2NhbGUgbG9jYWwgYnVzDQo+ID4gKwkgIGNvbnRyb2xsZXIuICBBbHNvIGNvbnRhaW5zIHNvbWUg
Y29tbW9uIGNvZGUgdXNlZCBieQ0KPiA+ICsJICBkcml2ZXJzIGZvciBzcGVjaWZpYyBsb2NhbCBi
dXMgcGVyaXBoZXJhbHMuDQo+ID4NCj4gPiAgY29uZmlnIEZTTF9HVE0NCj4gPiAgCWJvb2wNCj4g
Wy4uLl0NCj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfbGJjLmMgYi9h
cmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9sYmMuYw0KPiA+IGluZGV4IGRjZWI4ZDEuLjljOWU0NGYg
MTAwNjQ0DQo+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL3N5c2Rldi9mc2xfbGJjLmMNCj4gPiArKysg
Yi9hcmNoL3Bvd2VycGMvc3lzZGV2L2ZzbF9sYmMuYw0KPiA+IEBAIC01LDYgKzUsMTAgQEANCj4g
PiAgICoNCj4gPiAgICogQXV0aG9yOiBBbnRvbiBWb3JvbnRzb3YgPGF2b3JvbnRzb3ZAcnUubXZp
c3RhLmNvbT4NCj4gPiAgICoNCj4gPiArICogQ29weXJpZ2h0IChjKSAyMDEwIEZyZWVzY2FsZSBT
ZW1pY29uZHVjdG9yDQo+ID4gKyAqDQo+ID4gKyAqIEF1dGhvcnM6IEphY2sgTGFuIDxKYWNrLkxh
bkBmcmVlc2NhbGUuY29tPg0KPiANCj4gV291bGQgYmUgcHJldHRpZXIgaWYgeW91J2QgZ3JvdXAg
Y29weXJpZ2h0IGFuZCBhdXRob3JzaGlwIG5vdGljZXMuDQo+IEkuZS4NCj4gDQo+IENvcHlyaWdo
dCAyMDA4IE1WDQo+IENvcHlyaWdodCAyMDEwIEZTTA0KPiANCj4gQXV0aG9yczogQW50b24NCj4g
ICAgICAgICAgSmFjaw0KVGhlbiBob3cgdG8gcmVmbGVjdCB0aGUgcmVsYXRpb25zaGlwIG9mIHRo
ZSBBdXRob3IgYW5kIHRoZSBjb21wYW55PyBmcm9tIGVtYWlsIGFkZHJlc3M/DQoNCj4gDQo+ID4g
KyAqDQo+ID4gICAqIFRoaXMgcHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlz
dHJpYnV0ZSBpdCBhbmQvb3IgbW9kaWZ5DQo+ID4gICAqIGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0
aGUgR05VIEdlbmVyYWwgUHVibGljIExpY2Vuc2UgYXMgcHVibGlzaGVkIGJ5DQo+ID4gICAqIHRo
ZSBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVpdGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vu
c2UsIG9yDQo+ID4gQEAgLTIzLDM1ICsyNyw4IEBADQo+ID4gICNpbmNsdWRlIDxhc20vZnNsX2xi
Yy5oPg0KPiA+DQo+ID4gIHN0YXRpYyBzcGlubG9ja190IGZzbF9sYmNfbG9jayA9IF9fU1BJTl9M
T0NLX1VOTE9DS0VEKGZzbF9sYmNfbG9jayk7DQo+ID4gLXN0YXRpYyBzdHJ1Y3QgZnNsX2xiY19y
ZWdzIF9faW9tZW0gKmZzbF9sYmNfcmVnczsNCj4gPiAtDQo+ID4gLXN0YXRpYyBjaGFyIF9faW5p
dGRhdGEgKmNvbXBhdF9sYmNbXSA9IHsNCj4gPiAtCSJmc2wscHEyLWxvY2FsYnVzIiwNCj4gPiAt
CSJmc2wscHEycHJvLWxvY2FsYnVzIiwNCj4gPiAtCSJmc2wscHEzLWxvY2FsYnVzIiwNCj4gPiAt
CSJmc2wsZWxiYyIsDQo+ID4gLX07DQo+ID4gLQ0KPiA+IC1zdGF0aWMgaW50IF9faW5pdCBmc2xf
bGJjX2luaXQodm9pZCkNCj4gPiAtew0KPiA+IC0Jc3RydWN0IGRldmljZV9ub2RlICpsYnVzOw0K
PiA+IC0JaW50IGk7DQo+ID4gLQ0KPiA+IC0JZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUoY29t
cGF0X2xiYyk7IGkrKykgew0KPiA+IC0JCWxidXMgPSBvZl9maW5kX2NvbXBhdGlibGVfbm9kZShO
VUxMLCBOVUxMLCBjb21wYXRfbGJjW2ldKTsNCj4gPiAtCQlpZiAobGJ1cykNCj4gPiAtCQkJZ290
byBmb3VuZDsNCj4gPiAtCX0NCj4gPiAtCXJldHVybiAtRU5PREVWOw0KPiA+IC0NCj4gPiAtZm91
bmQ6DQo+ID4gLQlmc2xfbGJjX3JlZ3MgPSBvZl9pb21hcChsYnVzLCAwKTsNCj4gPiAtCW9mX25v
ZGVfcHV0KGxidXMpOw0KPiA+IC0JaWYgKCFmc2xfbGJjX3JlZ3MpDQo+ID4gLQkJcmV0dXJuIC1F
Tk9NRU07DQo+ID4gLQlyZXR1cm4gMDsNCj4gPiAtfQ0KPiA+IC1hcmNoX2luaXRjYWxsKGZzbF9s
YmNfaW5pdCk7DQo+ID4gK3N0cnVjdCBmc2xfbGJjX2N0cmwgKmZzbF9sYmNfY3RybF9kZXY7DQo+
ID4gK0VYUE9SVF9TWU1CT0woZnNsX2xiY19jdHJsX2Rldik7DQo+ID4NCj4gPiAgLyoqDQo+ID4g
ICAqIGZzbF9sYmNfZmluZCAtIGZpbmQgTG9jYWxidXMgYmFuaw0KPiA+IEBAIC02NiwxMiArNDMs
MTIgQEAgaW50IGZzbF9sYmNfZmluZChwaHlzX2FkZHJfdCBhZGRyX2Jhc2UpDQo+ID4gIHsNCj4g
PiAgCWludCBpOw0KPiA+DQo+ID4gLQlpZiAoIWZzbF9sYmNfcmVncykNCj4gPiArCWlmICghZnNs
X2xiY19jdHJsX2RldiB8fCAhZnNsX2xiY19jdHJsX2Rldi0+cmVncykNCj4gPiAgCQlyZXR1cm4g
LUVOT0RFVjsNCj4gPg0KPiA+IC0JZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUoZnNsX2xiY19y
ZWdzLT5iYW5rKTsgaSsrKSB7DQo+ID4gLQkJX19iZTMyIGJyID0gaW5fYmUzMigmZnNsX2xiY19y
ZWdzLT5iYW5rW2ldLmJyKTsNCj4gPiAtCQlfX2JlMzIgb3IgPSBpbl9iZTMyKCZmc2xfbGJjX3Jl
Z3MtPmJhbmtbaV0ub3IpOw0KPiA+ICsJZm9yIChpID0gMDsgaSA8IEFSUkFZX1NJWkUoZnNsX2xi
Y19jdHJsX2Rldi0+cmVncy0+YmFuayk7IGkrKykgew0KPiA+ICsJCV9fYmUzMiBiciA9IGluX2Jl
MzIoJmZzbF9sYmNfY3RybF9kZXYtPnJlZ3MtPmJhbmtbaV0uYnIpOw0KPiA+ICsJCV9fYmUzMiBv
ciA9IGluX2JlMzIoJmZzbF9sYmNfY3RybF9kZXYtPnJlZ3MtPmJhbmtbaV0ub3IpOw0KPiANCj4g
QSBkZWRpY2F0ZWQgdmFyaWFibGUgZm9yIHJlZ3Mgd291bGQgbWFrZSB0aGlzIG11Y2ggbW9yZSBy
ZWFkYWJsZT8NClllcy4gY29uc2lkZXJpbmcgdGhlIGZvbGxvd2luZyBjb25kaXRpb24gbGluZS4N
Cj4gDQo+ID4NCj4gPiAgCQlpZiAoYnIgJiBCUl9WICYmIChiciAmIG9yICYgQlJfQkEpID09IGFk
ZHJfYmFzZSkNCj4gPiAgCQkJcmV0dXJuIGk7DQo+ID4gQEAgLTk5LDE3ICs3NiwyMCBAQCBpbnQg
ZnNsX3VwbV9maW5kKHBoeXNfYWRkcl90IGFkZHJfYmFzZSwgc3RydWN0IGZzbF91cG0NCj4gKnVw
bSkNCj4gPiAgCWlmIChiYW5rIDwgMCkNCj4gPiAgCQlyZXR1cm4gYmFuazsNCj4gPg0KPiA+IC0J
YnIgPSBpbl9iZTMyKCZmc2xfbGJjX3JlZ3MtPmJhbmtbYmFua10uYnIpOw0KPiA+ICsJaWYgKCFm
c2xfbGJjX2N0cmxfZGV2IHx8ICFmc2xfbGJjX2N0cmxfZGV2LT5yZWdzKQ0KPiA+ICsJCXJldHVy
biAtRU5PREVWOw0KPiA+ICsNCj4gPiArCWJyID0gaW5fYmUzMigmZnNsX2xiY19jdHJsX2Rldi0+
cmVncy0+YmFua1tiYW5rXS5icik7DQo+ID4NCj4gPiAgCXN3aXRjaCAoYnIgJiBCUl9NU0VMKSB7
DQo+ID4gIAljYXNlIEJSX01TX1VQTUE6DQo+ID4gLQkJdXBtLT5teG1yID0gJmZzbF9sYmNfcmVn
cy0+bWFtcjsNCj4gPiArCQl1cG0tPm14bXIgPSAmZnNsX2xiY19jdHJsX2Rldi0+cmVncy0+bWFt
cjsNCj4gDQo+IERpdHRvLCBhIHZlcnkgcmVwZXRpdGl2ZSBzdHVmZiwgZGVzaXJlcyBhIHZhcmlh
YmxlIGZvciByZWdzPw0KQnV0IHRoZSBmYWN0IGlzIHRoYXQgdGhlIHZhcmlhYmxlIHJlcHJlc2Vu
dHMgZGlmZmVyZW50IHJlZyBhZGRyZXNzIGFjY29yZGluZyB0byB0aGUgY29uZGl0aW9uLiBJdCB3
aWxsIGJlIHVnbHkgdG8gdXNlIHRoZSByZWcgYWRkcmVzcyBkaXJlY3RvbHkuDQo+IA0KPiA+ICAJ
CWJyZWFrOw0KPiA+ICAJY2FzZSBCUl9NU19VUE1COg0KPiA+IC0JCXVwbS0+bXhtciA9ICZmc2xf
bGJjX3JlZ3MtPm1ibXI7DQo+ID4gKwkJdXBtLT5teG1yID0gJmZzbF9sYmNfY3RybF9kZXYtPnJl
Z3MtPm1ibXI7DQo+ID4gIAkJYnJlYWs7DQo+ID4gIAljYXNlIEJSX01TX1VQTUM6DQo+ID4gLQkJ
dXBtLT5teG1yID0gJmZzbF9sYmNfcmVncy0+bWNtcjsNCj4gPiArCQl1cG0tPm14bXIgPSAmZnNs
X2xiY19jdHJsX2Rldi0+cmVncy0+bWNtcjsNCj4gPiAgCQlicmVhazsNCj4gPiAgCWRlZmF1bHQ6
DQo+ID4gIAkJcmV0dXJuIC1FSU5WQUw7DQo+ID4gQEAgLTE0MywxNCArMTIzLDE4IEBAIEVYUE9S
VF9TWU1CT0woZnNsX3VwbV9maW5kKTsNCj4gPiAgICogdGh1cyBVUE0gcGF0dGVybiBhY3R1YWxs
eSBleGVjdXRlZC4gTm90ZSB0aGF0IG1hciB1c2FnZSBkZXBlbmRzIG9uIHRoZQ0KPiA+ICAgKiBw
cmUtcHJvZ3JhbW1lZCBBTVggYml0cyBpbiB0aGUgVVBNIFJBTS4NCj4gPiAgICovDQo+ID4gKw0K
PiA+ICBpbnQgZnNsX3VwbV9ydW5fcGF0dGVybihzdHJ1Y3QgZnNsX3VwbSAqdXBtLCB2b2lkIF9f
aW9tZW0gKmlvX2Jhc2UsIHUzMiBtYXIpDQo+ID4gIHsNCj4gPiAgCWludCByZXQgPSAwOw0KPiA+
ICAJdW5zaWduZWQgbG9uZyBmbGFnczsNCj4gPg0KPiA+ICsJaWYgKCFmc2xfbGJjX2N0cmxfZGV2
IHx8ICFmc2xfbGJjX2N0cmxfZGV2LT5yZWdzKQ0KPiA+ICsJCXJldHVybiAtRU5PREVWOw0KPiA+
ICsNCj4gPiAgCXNwaW5fbG9ja19pcnFzYXZlKCZmc2xfbGJjX2xvY2ssIGZsYWdzKTsNCj4gPg0K
PiA+IC0Jb3V0X2JlMzIoJmZzbF9sYmNfcmVncy0+bWFyLCBtYXIpOw0KPiA+ICsJb3V0X2JlMzIo
JmZzbF9sYmNfY3RybF9kZXYtPnJlZ3MtPm1hciwgbWFyKTsNCj4gPg0KPiA+ICAJc3dpdGNoICh1
cG0tPndpZHRoKSB7DQo+ID4gIAljYXNlIDg6DQo+ID4gQEAgLTE3MiwzICsxNTYsMTk3IEBAIGlu
dCBmc2xfdXBtX3J1bl9wYXR0ZXJuKHN0cnVjdCBmc2xfdXBtICp1cG0sIHZvaWQNCj4gX19pb21l
bSAqaW9fYmFzZSwgdTMyIG1hcikNCj4gPiAgCXJldHVybiByZXQ7DQo+ID4gIH0NCj4gPiAgRVhQ
T1JUX1NZTUJPTChmc2xfdXBtX3J1bl9wYXR0ZXJuKTsNCj4gPiArDQo+ID4gK3N0YXRpYyBpbnQg
X19kZXZpbml0IGZzbF9sYmNfY3RybF9pbml0KHN0cnVjdCBmc2xfbGJjX2N0cmwgKmN0cmwpDQo+
ID4gK3sNCj4gPiArCXN0cnVjdCBmc2xfbGJjX3JlZ3MgX19pb21lbSAqbGJjID0gY3RybC0+cmVn
czsNCj4gDQo+IFllcCwgc29tZXRoaW5nIGxpa2UgdGhpcyBmb3IgdGhlIGZ1bmN0aW9ucyBhYm92
ZS4NCkkgZG8gbm90IHNlZSBhbnkgaGFybSB0byBhZGQgYSB2YXJpYWJsZSBsYmMgaW4gdGhlIGZ1
bmN0aW9uIHRvIGluY3JlYXNlIHRoZSByZWFkYWJsZS4NCj4gDQo+ID4gKw0KPiA+ICsJLyogY2xl
YXIgZXZlbnQgcmVnaXN0ZXJzICovDQo+ID4gKwlzZXRiaXRzMzIoJmxiYy0+bHRlc3IsIExURVNS
X0NMRUFSKTsNCj4gPiArCW91dF9iZTMyKCZsYmMtPmx0ZWF0ciwgMCk7DQo+ID4gKwlvdXRfYmUz
MigmbGJjLT5sdGVhciwgMCk7DQo+ID4gKwlvdXRfYmUzMigmbGJjLT5sdGVjY3IsIExURUNDUl9D
TEVBUik7DQo+ID4gKwlvdXRfYmUzMigmbGJjLT5sdGVkciwgTFRFRFJfRU5BQkxFKTsNCj4gPiAr
DQo+ID4gKwkvKiBFbmFibGUgaW50ZXJydXB0cyBmb3IgYW55IGRldGVjdGVkIGV2ZW50cyAqLw0K
PiA+ICsJb3V0X2JlMzIoJmxiYy0+bHRlaXIsIExURUlSX0VOQUJMRSk7DQo+ID4gKw0KPiA+ICsJ
cmV0dXJuIDA7DQo+ID4gK30NCj4gPiArDQo+ID4gK3N0YXRpYyBpbnQgX19kZXZleGl0IGZzbF9s
YmNfY3RybF9yZW1vdmUoc3RydWN0IG9mX2RldmljZSAqb2ZkZXYpDQo+ID4gK3sNCj4gPiArCXN0
cnVjdCBmc2xfbGJjX2N0cmwgKmN0cmwgPSBkZXZfZ2V0X2RydmRhdGEoJm9mZGV2LT5kZXYpOw0K
PiA+ICsNCj4gPiArCWlmIChjdHJsLT5pcnEpDQo+ID4gKwkJZnJlZV9pcnEoY3RybC0+aXJxLCBj
dHJsKTsNCj4gPiArDQo+ID4gKwlpZiAoY3RybC0+cmVncykNCj4gPiArCQlpb3VubWFwKGN0cmwt
PnJlZ3MpOw0KPiA+ICsNCj4gPiArCWRldl9zZXRfZHJ2ZGF0YSgmb2ZkZXYtPmRldiwgTlVMTCk7
DQo+ID4gKwlrZnJlZShjdHJsKTsNCj4gPiArDQo+ID4gKwlyZXR1cm4gMDsNCj4gPiArfQ0KPiA+
ICsNCj4gPiArLyogTk9URTogVGhpcyBpbnRlcnJ1cHQgaXMgdXNlZCB0byByZXBvcnQgbG9jYWxi
dXMgZXZlbnRzIG9mIHZhcmlvdXMga2luZHMsDQo+ID4gKyAqIHN1Y2ggYXMgdHJhbnNhY3Rpb24g
ZXJyb3JzIG9uIHRoZSBjaGlwc2VsZWN0cy4NCj4gPiArICovDQo+IA0KPiAvKg0KPiAgKiBtdWx0
aSBsaW5lIGNvbW1lbnRzDQo+ICAqIHNob3VsZCBiZSBsaWtlIHRoaXMNCj4gICovDQpPSy4NCg0K
PiANCj4gWy4uLl0NCj4gPiArLyogZnNsX2xiY19jdHJsX3Byb2JlDQo+ID4gKyAqDQo+ID4gKyAq
IGNhbGxlZCBieSBkZXZpY2UgbGF5ZXIgd2hlbiBpdCBmaW5kcyBhIGRldmljZSBtYXRjaGluZw0K
PiA+ICsgKiBvbmUgb3VyIGRyaXZlciBjYW4gaGFuZGxlZC4gVGhpcyBjb2RlIGFsbG9jYXRlcyBh
bGwgb2YNCj4gPiArICogdGhlIHJlc291cmNlcyBuZWVkZWQgZm9yIHRoZSBjb250cm9sbGVyIG9u
bHkuICBUaGUNCj4gPiArICogcmVzb3VyY2VzIGZvciB0aGUgTkFORCBiYW5rcyB0aGVtc2VsdmVz
IGFyZSBhbGxvY2F0ZWQNCj4gPiArICogaW4gdGhlIGNoaXAgcHJvYmUgZnVuY3Rpb24uDQo+ID4g
KyovDQo+IA0KPiBkaXR0by4NCk9LLg0KPiANCj4gPiArc3RhdGljIGludCBfX2RldmluaXQgZnNs
X2xiY19jdHJsX3Byb2JlKHN0cnVjdCBvZl9kZXZpY2UgKm9mZGV2LA0KPiA+ICsJCQkJCSBjb25z
dCBzdHJ1Y3Qgb2ZfZGV2aWNlX2lkICptYXRjaCkNCj4gPiArew0KPiA+ICsJaW50IHJldCA9IDA7
DQo+IA0KPiBubyBuZWVkIGZvciB0aGUgaW5pdGlhbCB2YWx1ZSBoZXJlLg0KQW55IGhhcm0/DQoN
Cj4gDQo+ID4gKw0KPiA+ICsJZnNsX2xiY19jdHJsX2RldiA9IGt6YWxsb2Moc2l6ZW9mKCpmc2xf
bGJjX2N0cmxfZGV2KSwgR0ZQX0tFUk5FTCk7DQo+ID4gKwlpZiAoIWZzbF9sYmNfY3RybF9kZXYp
DQo+ID4gKwkJcmV0dXJuIC1FTk9NRU07DQo+ID4gKw0KPiA+ICsJZGV2X3NldF9kcnZkYXRhKCZv
ZmRldi0+ZGV2LCBmc2xfbGJjX2N0cmxfZGV2KTsNCj4gPiArDQo+ID4gKwlzcGluX2xvY2tfaW5p
dCgmZnNsX2xiY19jdHJsX2Rldi0+bG9jayk7DQo+ID4gKwlpbml0X3dhaXRxdWV1ZV9oZWFkKCZm
c2xfbGJjX2N0cmxfZGV2LT5pcnFfd2FpdCk7DQo+ID4gKw0KPiA+ICsJZnNsX2xiY19jdHJsX2Rl
di0+cmVncyA9IG9mX2lvbWFwKG9mZGV2LT5kZXYub2Zfbm9kZSwgMCk7DQo+ID4gKwlpZiAoIWZz
bF9sYmNfY3RybF9kZXYtPnJlZ3MpIHsNCj4gPiArCQlkZXZfZXJyKCZvZmRldi0+ZGV2LCAiZmFp
bGVkIHRvIGdldCBtZW1vcnkgcmVnaW9uXG4iKTsNCj4gPiArCQlyZXQgPSAtRU5PREVWOw0KPiA+
ICsJCWdvdG8gZXJyOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCWZzbF9sYmNfY3RybF9kZXYtPmly
cSA9IG9mX2lycV90b19yZXNvdXJjZShvZmRldi0+ZGV2Lm9mX25vZGUsIDAsIE5VTEwpOw0KPiA+
ICsJaWYgKGZzbF9sYmNfY3RybF9kZXYtPmlycSA9PSBOT19JUlEpIHsNCj4gPiArCQlkZXZfZXJy
KCZvZmRldi0+ZGV2LCAiZmFpbGVkIHRvIGdldCBpcnEgcmVzb3VyY2VcbiIpOw0KPiA+ICsJCXJl
dCA9IC1FTk9ERVY7DQo+ID4gKwkJZ290byBlcnI7DQo+ID4gKwl9DQo+ID4gKw0KPiA+ICsJZnNs
X2xiY19jdHJsX2Rldi0+ZGV2ID0gJm9mZGV2LT5kZXY7DQo+ID4gKw0KPiA+ICsJcmV0ID0gZnNs
X2xiY19jdHJsX2luaXQoZnNsX2xiY19jdHJsX2Rldik7DQo+ID4gKwlpZiAocmV0IDwgMCkNCj4g
PiArCQlnb3RvIGVycjsNCj4gPiArDQo+ID4gKwlyZXQgPSByZXF1ZXN0X2lycShmc2xfbGJjX2N0
cmxfZGV2LT5pcnEsIGZzbF9sYmNfY3RybF9pcnEsIDAsDQo+ID4gKwkJCQkiZnNsLWxiYyIsIGZz
bF9sYmNfY3RybF9kZXYpOw0KPiA+ICsJaWYgKHJldCAhPSAwKSB7DQo+ID4gKwkJZGV2X2Vycigm
b2ZkZXYtPmRldiwgImZhaWxlZCB0byBpbnN0YWxsIGlycSAoJWQpXG4iLA0KPiA+ICsJCQlmc2xf
bGJjX2N0cmxfZGV2LT5pcnEpOw0KPiA+ICsJCXJldCA9IGZzbF9sYmNfY3RybF9kZXYtPmlycTsN
Cj4gPiArCQlnb3RvIGVycjsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwlyZXR1cm4gMDsNCj4gPiAr
DQo+ID4gK2VycjoNCj4gDQo+IGZzbF9sYmNfY3RybF9kZXYgbGVha2VkLiBQbHVzLCBhZnRlciBm
cmVlaW5nIGl0LCB5b3Ugc2hvdWxkDQo+IE5VTExpZnkgaXQgYXMgd2VsbCwgYXMgb3RoZXIgZnVu
Y3Rpb25zIGNoZWNrcyBpdCBmb3IgIU5VTEwuDQpBZ3JlZS4NCj4gDQo+IGZzbF9sYmNfY3RybF9k
ZXYtPnJlZ3MgbGVha3MgdG9vLg0KQWdyZWUuDQo+IA0KPiA+ICsJcmV0dXJuIHJldDsNCj4gPiAr
fQ0KPiA+ICsNCj4gPiArc3RhdGljIGNvbnN0IHN0cnVjdCBvZl9kZXZpY2VfaWQgZnNsX2xiY19t
YXRjaFtdID0gew0KPiA+ICsJew0KPiA+ICsJCS5jb21wYXRpYmxlID0gImZzbCxlbGJjIiwNCj4g
PiArCX0sDQo+ID4gKwl7DQo+ID4gKwkJLmNvbXBhdGlibGUgPSAiZnNsLHBxMy1sb2NhbGJ1cyIs
DQo+ID4gKwl9LA0KPiA+ICsJew0KPiA+ICsJCS5jb21wYXRpYmxlID0gImZzbCxwcTItbG9jYWxi
dXMiLA0KPiA+ICsJfSwNCj4gPiArCXsNCj4gPiArCQkuY29tcGF0aWJsZSA9ICJmc2wscHEycHJv
LWxvY2FsYnVzIiwNCj4gPiArCX0sDQo+ID4gKwl7fSwNCj4gDQo+IENvdWxkIHNhdmUgOCBsaW5l
cyBieSB3cml0aW5nICJ7IC5jb21wYXRpYmxlID0gIi4uLiIsIH0sIi4NCg0KQWdyZWUuDQo+IA0K
PiA+ICt9Ow0KPiA+ICsNCj4gPiArc3RhdGljIHN0cnVjdCBvZl9wbGF0Zm9ybV9kcml2ZXIgZnNs
X2xiY19jdHJsX2RyaXZlciA9IHsNCj4gDQo+IEkgdGhpbmsgeW91IHNob3VsZG4ndCB1c2Ugb2Zf
cGxhdGZvcm0gZm9yIG5ldyBjb2RlLiBqdXN0IHBsYXRmb3JtDQo+IHdpbGwgd29yayAodGhlcmUn
cyBwbGF0Zm9ybV9kcml2ZXIuZHJpdmVyLm9mX21hdGNoX3RhYmxlIG5vd2FkYXlzKS4NCj4gDQo+
ID4gKwkuZHJpdmVyID0gew0KPiA+ICsJCS5uYW1lID0gImZzbC1sYmMiLA0KPiA+ICsJCS5vZl9t
YXRjaF90YWJsZSA9IGZzbF9sYmNfbWF0Y2gsDQo+ID4gKwl9LA0KPiA+ICsJLnByb2JlID0gZnNs
X2xiY19jdHJsX3Byb2JlLA0KPiA+ICsJLnJlbW92ZSA9IF9fZGV2ZXhpdF9wKGZzbF9sYmNfY3Ry
bF9yZW1vdmUpLA0KPiANCj4gVGhlIGRldmljZSBpcyBub3QgcmVtb3ZhYmxlLCBJIHRoaW5rIHlv
dSBkb24ndCBuZWVkIHRoaXMuDQpBZ3JlZS4NCg0KPiANCj4gPiArfTsNCj4gPiArDQo+ID4gK3N0
YXRpYyBpbnQgX19pbml0IGZzbF9sYmNfaW5pdCh2b2lkKQ0KPiA+ICt7DQo+ID4gKwlyZXR1cm4g
b2ZfcmVnaXN0ZXJfcGxhdGZvcm1fZHJpdmVyKCZmc2xfbGJjX2N0cmxfZHJpdmVyKTsNCj4gPiAr
fQ0KPiA+ICsNCj4gPiArc3RhdGljIHZvaWQgX19leGl0IGZzbF9sYmNfZXhpdCh2b2lkKQ0KPiA+
ICt7DQo+ID4gKwlvZl91bnJlZ2lzdGVyX3BsYXRmb3JtX2RyaXZlcigmZnNsX2xiY19jdHJsX2Ry
aXZlcik7DQo+ID4gK30NCj4gPiArDQo+ID4gK21vZHVsZV9pbml0KGZzbF9sYmNfaW5pdCk7DQo+
ID4gK21vZHVsZV9leGl0KGZzbF9sYmNfZXhpdCk7DQo+IA0KPiBmc2xfbGJjIGlzIG5vdCBhIG1v
ZHVsZSwgc28geW91IGRvbid0IG5lZWQgX2V4aXQoKS4NCkFncmVlLg0KPiANCj4gPiArTU9EVUxF
X0xJQ0VOU0UoIkdQTCIpOw0KPiA+ICtNT0RVTEVfQVVUSE9SKCJGcmVlc2NhbGUgU2VtaWNvbmR1
Y3RvciIpOw0KPiA+ICtNT0RVTEVfREVTQ1JJUFRJT04oIkZyZWVzY2FsZSBFbmhhbmNlZCBMb2Nh
bCBCdXMgQ29udHJvbGxlciBkcml2ZXIiKTsNCj4gDQo+IGRpdHRvLCBubyBuZWVkIGZvciB0aGlz
Lg0KQWdyZWUuDQpUaGFua3MuDQpSb3kNCg==
^ permalink raw reply
* RE: [PATCH 2/3][MTD] P4080/nand: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-06 3:40 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100903114357.GC11847@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMDMsIDIwMTAgMTk6NDQgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODA7IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zXVtNVERdIFA0
MDgwL25hbmQ6IE9ubHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdA0KPiBuYW5kIGZsYXNo
IHBhcnRpdGlvbnMNCj4gDQo+IE9uIEZyaSwgQXVnIDA2LCAyMDEwIGF0IDEwOjUxOjM1QU0gKzA4
MDAsIFJveSBaYW5nIHdyb3RlOg0KPiBbLi4uXQ0KPiA+DQo+ID4gK3N0YXRpYyBzdHJ1Y3QgZnNs
X2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmw7DQo+ID4gKw0KPiANCj4gQXJlIHlvdSBzdXJl
IHRoYXQgeW91IHdhbnQgaXQgYXMgYSBnbG9iYWwgdmFyPyBBIGJpdCBzY2FyeSBjaGFuZ2UuDQo+
IA0KPiBPaCwgeW91IHByb2JhYmx5IGRvbid0IG5lZWQgaXQsIGFzIHlvdSBjYW4gZ2V0IGl0IGZy
b20NCj4gZnNsX2xiY19jdHJsX2Rldi0+bmFuZD8NCj4gDQo+IEkgd29uZGVyIGlmIFNjb3R0IHNh
dyB0aGVzZSBwYXRjaGVzPyBDYydlZC4NClllcy4NClJveQ0K
^ permalink raw reply
* RE: [PATCH 3/3][MTD] P4080/nand: Fix the freescale lbc issue with 36bit mode
From: Zang Roy-R61911 @ 2010-09-06 3:56 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Lan Chunhe-B25806, linuxppc-dev, akpm, linux-mtd,
Gala Kumar-B11780
In-Reply-To: <20100903113604.GB11847@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMDMsIDIwMTAgMTk6MzYgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODANCj4gU3ViamVjdDogUmU6IFtQQVRDSCAzLzNdW01URF0gUDQwODAvbmFuZDogRml4IHRoZSBm
cmVlc2NhbGUgbGJjIGlzc3VlIHdpdGgNCj4gMzZiaXQgbW9kZQ0KPiANCj4gT24gRnJpLCBBdWcg
MDYsIDIwMTAgYXQgMTA6NTE6MzZBTSArMDgwMCwgUm95IFphbmcgd3JvdGU6DQo+IFsuLi5dDQo+
ID4gIC8qKg0KPiA+ICsgKiBjb252ZXJ0X2xiY19hZGRyZXNzIC0gY29udmVydCB0aGUgYmFzZSBh
ZGRyZXNzDQo+ID4gKyAqIEBhZGRyX2Jhc2U6CWJhc2UgYWRkcmVzcyBvZiB0aGUgbWVtb3J5IGJh
bmsNCj4gPiArICoNCj4gPiArICogVGhpcyBmdW5jdGlvbiBjb252ZXJ0cyBhIGJhc2UgYWRkcmVz
cyBvZiBsYmMgaW50byB0aGUgcmlnaHQgZm9ybWF0IGZvcg0KPiB0aGUgQlINCj4gPiArICogcmVn
aXN0ZXJzLiBJZiB0aGUgU09DIGhhcyBlTEJDIHRoZW4gaXQgcmV0dXJucyAzMmJpdCBwaHlzaWNh
bCBhZGRyZXNzDQo+IGVsc2UNCj4gPiArICogaXQgcmV0dXJucyAzNGJpdCBwaHlzaWNhbCBhZGRy
ZXNzIGZvciBsb2NhbCBidXMoRXhhbXBsZTogTVBDODY0MSkuDQo+ID4gKyAqLw0KPiA+ICt1bnNp
Z25lZCBpbnQgY29udmVydF9sYmNfYWRkcmVzcyhwaHlzX2FkZHJfdCBhZGRyX2Jhc2UpDQo+ID4g
K3sNCj4gPiArCXZvaWQgKmRldjsNCj4gPiArCWludCBjb21wYXRpYmxlOw0KPiA+ICsNCj4gPiAr
CWRldiA9IG9mX2ZpbmRfbm9kZV9ieV9uYW1lKE5VTEwsICJsb2NhbGJ1cyIpOw0KPiANCj4gTm9w
ZSwgeW91IHNob3VsZG4ndCBkbyB0aGlzLiBOZXZlciBzZWFyY2ggYnkgbmFtZS4NCk9LLiBJIHdp
bGwgc2VhcmNoIGJ5IGNvbXBhdGlibGUuDQo+IA0KPiBBbHNvLCBhcmVuJ3QgdGhlcmUgYWxyZWFk
eSBhIGdsb2JhbCBkZXYsIHdoaWNoIHdhcyBmb3VuZCBieSB0aGUNCj4gX3Byb2JlKCkgc3R1ZmY/
DQpJIGRvIG5vdCBzZWUgdGhlIGdsb2JhbCBkZXYgY2FuIGJlIHVzZWQgaW4gcHJvYmUuDQoNCj4g
DQo+ID4gKwlpZiAoIWRldikgew0KPiA+ICsJCXByaW50ayhLRVJOX0lORk8gImZzbC1sYmM6IGNh
bid0IGZpbmQgbG9jYWxidXMgbm9kZVxuIik7DQo+ID4gKwkJb2Zfbm9kZV9wdXQoZGV2KTsNCj4g
PiArCQlyZXR1cm4gMDsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwljb21wYXRpYmxlID0gb2ZfZGV2
aWNlX2lzX2NvbXBhdGlibGUoZGV2LCAiZnNsLGVsYmMiKTsNCj4gPiArCW9mX25vZGVfcHV0KGRl
dik7DQo+ID4gKwlpZiAoY29tcGF0aWJsZSkNCj4gPiArCQlyZXR1cm4gYWRkcl9iYXNlICYgMHhm
ZmZmODAwMDsNCj4gPiArCWVsc2UNCj4gPiArCQlyZXR1cm4gKGFkZHJfYmFzZSAmIDB4MGZmZmY4
MDAwdWxsKSBcDQo+ID4gKwkJCXwgKChhZGRyX2Jhc2UgJiAweDMwMDAwMDAwMHVsbCkgPj4gMTkp
Ow0KPiA+ICt9DQo+ID4gK0VYUE9SVF9TWU1CT0woY29udmVydF9sYmNfYWRkcmVzcyk7DQo+ID4g
Kw0KPiA+ICsvKioNCj4gPiAgICogZnNsX2xiY19maW5kIC0gZmluZCBMb2NhbGJ1cyBiYW5rDQo+
ID4gICAqIEBhZGRyX2Jhc2U6CWJhc2UgYWRkcmVzcyBvZiB0aGUgbWVtb3J5IGJhbmsNCj4gPiAg
ICoNCj4gPiBAQCAtNTAsNyArODAsOCBAQCBpbnQgZnNsX2xiY19maW5kKHBoeXNfYWRkcl90IGFk
ZHJfYmFzZSkNCj4gPiAgCQlfX2JlMzIgYnIgPSBpbl9iZTMyKCZmc2xfbGJjX2N0cmxfZGV2LT5y
ZWdzLT5iYW5rW2ldLmJyKTsNCj4gPiAgCQlfX2JlMzIgb3IgPSBpbl9iZTMyKCZmc2xfbGJjX2N0
cmxfZGV2LT5yZWdzLT5iYW5rW2ldLm9yKTsNCj4gPg0KPiA+IC0JCWlmIChiciAmIEJSX1YgJiYg
KGJyICYgb3IgJiBCUl9CQSkgPT0gYWRkcl9iYXNlKQ0KPiA+ICsJCWlmIChiciAmIEJSX1YgJiYg
KGJyICYgb3IgJiBCUl9CQSkgXA0KPiANCj4gTm8gbmVlZCBmb3IgIlwiIGF0IHRoZSBlbmQgb2Yg
dGhlIGxpbmUsIGtlZXAgPT0gb24gdGhlIHNhbWUgbGluZS4NCj4gDQo+ID4gKwkJCQk9PSBjb252
ZXJ0X2xiY19hZGRyZXNzKGFkZHJfYmFzZSkpDQo+IA0KPiBXb3VsZCBiZSBwcmV0dGllciBpZiB5
b3UgbmFtZSBpdCBmc2xfbGJjX2FkZHIoKS4gS2VlcHMgcHJlZml4DQo+IHRoZSBzYW1lIGZvciB0
aGUgcmVzdCBvZiB0aGUgZmlsZSwgcGx1cyBtYWtlcyBpdCBzaG9ydGVyIChzbw0KPiB0aGVyZSBw
cm9iYWJseSB3b24ndCBiZSBhbnkgbmVlZCBmb3IgYnJlYWtpbmcgdGhlIGxpbmUpLg0KQWdyZWUg
dGhlIG5ldyBuYW1lLg0KVGhhbmtzLg0KUm95DQo=
^ permalink raw reply
* RE: [PATCH 2/3][MTD] P4080/nand: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-06 4:49 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100903114357.GC11847@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogRnJpZGF5LCBTZXB0ZW1i
ZXIgMDMsIDIwMTAgMTk6NDQgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODA7IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zXVtNVERdIFA0
MDgwL25hbmQ6IE9ubHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdA0KPiBuYW5kIGZsYXNo
IHBhcnRpdGlvbnMNCj4gDQo+IE9uIEZyaSwgQXVnIDA2LCAyMDEwIGF0IDEwOjUxOjM1QU0gKzA4
MDAsIFJveSBaYW5nIHdyb3RlOg0KPiBbLi4uXQ0KPiA+DQo+ID4gK3N0YXRpYyBzdHJ1Y3QgZnNs
X2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmw7DQo+ID4gKw0KPiANCj4gQXJlIHlvdSBzdXJl
IHRoYXQgeW91IHdhbnQgaXQgYXMgYSBnbG9iYWwgdmFyPyBBIGJpdCBzY2FyeSBjaGFuZ2UuDQo+
IA0KPiBPaCwgeW91IHByb2JhYmx5IGRvbid0IG5lZWQgaXQsIGFzIHlvdSBjYW4gZ2V0IGl0IGZy
b20NCj4gZnNsX2xiY19jdHJsX2Rldi0+bmFuZD8NCkdldCBpdCBmb3JtIGZzbF9sYmNfY3RybF9k
ZXYtPm5hbmQgb3IgYXNzaWduIGl0IHRvIGZzbF9sYmNfY3RybF9kZXYtPm5hbmQgaW4gcHJvYmU/
DQpUaGFua3MuDQpSb3kNCg0K
^ permalink raw reply
* RE: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Tirumala Marri @ 2010-09-06 5:19 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20100905222340.GC2150@lixom.net>
>
> Then the device tree identifier, and the cpu setup functions, etc,
> should indicate
> 464, not APM821xx.
This is new SoC based on 464 cpu core. All the previous SoC device tree
CPU portion uses SoC name.
>
> Also, why add yet another defconfig? Isn't the eval board similar to
> many others and can be supported with just a tweak of some existing
> common defconfig instead?
>
Every new board needs new defconfig. And it is not same as others. It has
Different features from other.
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Richard Cochran @ 2010-09-06 6:33 UTC (permalink / raw)
To: John Stultz
Cc: Rodolfo Giometti, Arnd Bergmann, netdev, devicetree-discuss,
linux-kernel, linuxppc-dev, linux-arm-kernel, Krzysztof Halasa
In-Reply-To: <1282948239.2268.155.camel@jstultz-laptop>
On Fri, Aug 27, 2010 at 03:30:39PM -0700, John Stultz wrote:
> On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote:
> > We have not introduced new PPS interface. We use existing PPS subsystem.
>
> Doesn't the pps subsystem have its own way to control the pps signal
> interrupt? I'm not totally sure here, but given your point above that
> having multiple pps events it seems like they should be selectable. It
> seems something that we'd want to control via the global pps interface,
> rather then having a pps-enable flag on every random bit of hardware
> that can support it.
The PPS subsystem offers no way to disable PPS interrupts.
> > > Same for the timestamps and periodic output (ie: and how do they differ
> > > from reading or setting a timer on CLOCK_PTP?)
> >
> > The posix timer calls won't work:
> >
> > I have a PTP hardware clocks with multiple external timestamp
> > channels. Using timer_gettime, how can I specify (or decode) the
> > channel of interest to me?
>
> I guess I'm not following you here. Again, I'm not super familiar with
> the hardware involved. Could you clarify a bit more? What do you mean by
> external timestamp? Is this what is used on the packet timestamping?
No, the packet timestamp occurs in the PHY, MAC, or on the MII bus and
is an essential feature to support the PTP.
An external timestamp is just a wire going into the clock and is an
optional feature to make the clock more useful. The clock can latch
the current time value when an edge is dectected on the wire. Using
external timestamps, you correlate real world events with the absolute
time in the clock.
Typically, a clock offers two or more such input channels (wires), but
timer_gettime does not offer a way to differentiate between them, and
thus is not suitable.
> The posix clock id interface is frustrating because the flat static
> enumeration is really limiting.
>
> I wonder if a dynamic enumeration for posix clocks would be possibly a
> way to go?
I am perfectly happy with this.
> In other words, a driver registers a clock with the system, and the
> system reserves a clock_id for it from the designated available pool and
> assigns it back. Then userland could query the driver via something like
> sysfs to get the clockid for the hardware.
>
> Would that maybe work?
I have now posted a sample implementation of this idea. Do you like it?
> > The sysfs will include one class device for each PTP clock. Each clock
> > has a sysfs attribute with the corresponding clock id.
>
> Do you mean the clock_id # in the posix clocks namespace?
Yes.
> > I would also be happy with the character device idea already
> > posted. Just pick one of the two, and I'll resubmit the patch set...
>
> Personally, with regard to exposing the ptp clock to userland I'm more
> comfortable via the chardev. However, the posix clocks/timer api is
> really close to what you need, so I'm not totally set against it. And
> maybe the dynamic enumeration would resolve my main problems with it?
Okay, I have posted a draft of the dynamic idea. Can you support it?
> That said, with the chardev method, I don't like the idea of duplicating
> the existing time apis via a systemtime device. Dropping that from your
> earlier patch would ease the majority of my objections.
Well, the clock interface needs to offer basic services:
1. Set time
2. Get time
3. Jump offset
4. Adjust frequency
This is similar to what the posix clock and ntp API offer. Using a
chardev, should I make the ioctls really different, just for the
purpose of being different?
To me, it makes more sense to offer a familiar interface.
I was perfectly happy with the chardev idea. In fact, that is the way
I first implemented it. Now, I have also gone ahead and implemented
the dynamic posix clock idea, too.
> > At this point I would just like to go forward with one of the two
> > proposed APIs. I had modelled the character device on the posix clock
> > calls in order to make it immediately familar, and I think it is a
> > viable approach. After the lkml discussion, I think it is even cleaner
> > and nicer to just offer a new clock id.
I would like to repeat the sentiment in this last paragraph! I already
implemented and would be content with either form for the new clock
control API:
1. Character device
2. POSIX clock with dynamic ids
Please, just take your pick ;^)
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH 2/3][MTD] P4080/nand: Only make elbc nand driver detect nand flash partitions
From: Anton Vorontsov @ 2010-09-06 8:09 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1B37B0@zch01exm23.fsl.freescale.net>
On Mon, Sep 06, 2010 at 12:49:17PM +0800, Zang Roy-R61911 wrote:
> > On Fri, Aug 06, 2010 at 10:51:35AM +0800, Roy Zang wrote:
> > [...]
> > >
> > > +static struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl;
> > > +
> >
> > Are you sure that you want it as a global var? A bit scary change.
> >
> > Oh, you probably don't need it, as you can get it from
> > fsl_lbc_ctrl_dev->nand?
> Get it form fsl_lbc_ctrl_dev->nand or assign it to
> fsl_lbc_ctrl_dev->nand in probe?
I meant to get it from fsl_lbc_ctrl_dev->nand. I.e. in
probe() you do: fsl_lbc_ctrl_dev->nand = elbc_fcm_ctrl, so
you probably don't need the global var.
(fsl_lbc_ctrl_dev seems to be global as well, duh. Well,
one variable less in the global name space. But I'd
probably use lbc_np->data to store the LBC private
struct).
Scott seem to be fine with it as there are probably no
plans to to add several localbus controllers into the SoCs.
But, I saw a custom board with two MPC82xx SoCs connected
together, one as a master (core + peripheral devs), and
other as a slave (its core was halted, and only slave's
CPM peripheral devices were used by the master CPU).
I think it is possible to connect two (or more) SoCs in
a such way so that two or more LBC controllers would
be visible for the Linux.
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-06 8:21 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1B378F@zch01exm23.fsl.freescale.net>
On Mon, Sep 06, 2010 at 11:38:09AM +0800, Zang Roy-R61911 wrote:
[...]
> > > switch (br & BR_MSEL) {
> > > case BR_MS_UPMA:
> > > - upm->mxmr = &fsl_lbc_regs->mamr;
> > > + upm->mxmr = &fsl_lbc_ctrl_dev->regs->mamr;
> >
> > Ditto, a very repetitive stuff, desires a variable for regs?
> But the fact is that the variable represents different reg
> address according to the condition. It will be ugly to use
> the reg address directoly.
I meant a dedicated var for 'fsl_lbc_ctrl_dev->regs'.
I.e.
regs = fsl_lbc_ctrl_dev->regs;
...
mxmr = ®s->mamr;
...
mxmr = ®s->mbmr;
..
mxmr = ®s->mcmr;
Instead of
mxmr = &fsl_lbc_ctrl_dev->regs->mamr;
...
mxmr = &fsl_lbc_ctrl_dev->regs->mbmr;
..
mxmr = &fsl_lbc_ctrl_dev->regs->mcmr;
[...]
> > > +static int __devinit fsl_lbc_ctrl_probe(struct of_device *ofdev,
> > > + const struct of_device_id *match)
> > > +{
> > > + int ret = 0;
> >
> > no need for the initial value here.
> Any harm?
Probably not as gcc will likely optimize it away,
but it's not needed, so why keep it there?
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 2/3][MTD] P4080/nand: Only make elbc nand driver detect nand flash partitions
From: Zang Roy-R61911 @ 2010-09-06 8:38 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100906080938.GA13755@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1i
ZXIgMDYsIDIwMTAgMTY6MTAgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODA7IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8zXVtNVERdIFA0
MDgwL25hbmQ6IE9ubHkgbWFrZSBlbGJjIG5hbmQgZHJpdmVyIGRldGVjdA0KPiBuYW5kIGZsYXNo
IHBhcnRpdGlvbnMNCj4gDQo+IE9uIE1vbiwgU2VwIDA2LCAyMDEwIGF0IDEyOjQ5OjE3UE0gKzA4
MDAsIFphbmcgUm95LVI2MTkxMSB3cm90ZToNCj4gPiA+IE9uIEZyaSwgQXVnIDA2LCAyMDEwIGF0
IDEwOjUxOjM1QU0gKzA4MDAsIFJveSBaYW5nIHdyb3RlOg0KPiA+ID4gWy4uLl0NCj4gPiA+ID4N
Cj4gPiA+ID4gK3N0YXRpYyBzdHJ1Y3QgZnNsX2VsYmNfZmNtX2N0cmwgKmVsYmNfZmNtX2N0cmw7
DQo+ID4gPiA+ICsNCj4gPiA+DQo+ID4gPiBBcmUgeW91IHN1cmUgdGhhdCB5b3Ugd2FudCBpdCBh
cyBhIGdsb2JhbCB2YXI/IEEgYml0IHNjYXJ5IGNoYW5nZS4NCj4gPiA+DQo+ID4gPiBPaCwgeW91
IHByb2JhYmx5IGRvbid0IG5lZWQgaXQsIGFzIHlvdSBjYW4gZ2V0IGl0IGZyb20NCj4gPiA+IGZz
bF9sYmNfY3RybF9kZXYtPm5hbmQ/DQo+ID4gR2V0IGl0IGZvcm0gZnNsX2xiY19jdHJsX2Rldi0+
bmFuZCBvciBhc3NpZ24gaXQgdG8NCj4gPiBmc2xfbGJjX2N0cmxfZGV2LT5uYW5kIGluIHByb2Jl
Pw0KPiANCj4gSSBtZWFudCB0byBnZXQgaXQgZnJvbSBmc2xfbGJjX2N0cmxfZGV2LT5uYW5kLiBJ
LmUuIGluDQo+IHByb2JlKCkgeW91IGRvOiBmc2xfbGJjX2N0cmxfZGV2LT5uYW5kID0gZWxiY19m
Y21fY3RybCwgc28NCj4geW91IHByb2JhYmx5IGRvbid0IG5lZWQgdGhlIGdsb2JhbCB2YXIuDQo+
IA0KPiAoZnNsX2xiY19jdHJsX2RldiBzZWVtcyB0byBiZSBnbG9iYWwgYXMgd2VsbCwgZHVoLiBX
ZWxsLA0KPiBvbmUgdmFyaWFibGUgbGVzcyBpbiB0aGUgZ2xvYmFsIG5hbWUgc3BhY2UuIEJ1dCBJ
J2QNCj4gcHJvYmFibHkgdXNlIGxiY19ucC0+ZGF0YSB0byBzdG9yZSB0aGUgTEJDIHByaXZhdGUN
Cj4gc3RydWN0KS4NClRoYXQgbWFrZXMgc2Vuc2UuDQo+IA0KPiBTY290dCBzZWVtIHRvIGJlIGZp
bmUgd2l0aCBpdCBhcyB0aGVyZSBhcmUgcHJvYmFibHkgbm8NCj4gcGxhbnMgdG8gdG8gYWRkIHNl
dmVyYWwgbG9jYWxidXMgY29udHJvbGxlcnMgaW50byB0aGUgU29Dcy4NCj4gDQo+IEJ1dCwgSSBz
YXcgYSBjdXN0b20gYm9hcmQgd2l0aCB0d28gTVBDODJ4eCBTb0NzIGNvbm5lY3RlZA0KPiB0b2dl
dGhlciwgb25lIGFzIGEgbWFzdGVyIChjb3JlICsgcGVyaXBoZXJhbCBkZXZzKSwgYW5kDQo+IG90
aGVyIGFzIGEgc2xhdmUgKGl0cyBjb3JlIHdhcyBoYWx0ZWQsIGFuZCBvbmx5IHNsYXZlJ3MNCj4g
Q1BNIHBlcmlwaGVyYWwgZGV2aWNlcyB3ZXJlIHVzZWQgYnkgdGhlIG1hc3RlciBDUFUpLg0KPiAN
Cj4gSSB0aGluayBpdCBpcyBwb3NzaWJsZSB0byBjb25uZWN0IHR3byAob3IgbW9yZSkgU29DcyBp
bg0KPiBhIHN1Y2ggd2F5IHNvIHRoYXQgdHdvIG9yIG1vcmUgTEJDIGNvbnRyb2xsZXJzIHdvdWxk
DQo+IGJlIHZpc2libGUgZm9yIHRoZSBMaW51eC4NClRoYXQgaXMgYW4gaW50ZXJlc3RpbmcgY2Fz
ZS4gRG8geW91IGhhdmUgYW55IHRob3VnaHQgaGVyZT8NClRoYW5rcy4NClJveQ0K
^ permalink raw reply
* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-09-06 9:24 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100906082142.GB13755@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1i
ZXIgMDYsIDIwMTAgMTY6MjIgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODA7IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8zXVtNVERdIFA0
MDgwL2VMQkM6IE1ha2UgRnJlZXNjYWxlIGVsYmMgaW50ZXJydXB0IGNvbW1vbg0KPiB0byBlbGJj
IGRldmljZXMNCj4gDQo+IE9uIE1vbiwgU2VwIDA2LCAyMDEwIGF0IDExOjM4OjA5QU0gKzA4MDAs
IFphbmcgUm95LVI2MTkxMSB3cm90ZToNCj4gWy4uLl0NCj4gPiA+ID4gIAlzd2l0Y2ggKGJyICYg
QlJfTVNFTCkgew0KPiA+ID4gPiAgCWNhc2UgQlJfTVNfVVBNQToNCj4gPiA+ID4gLQkJdXBtLT5t
eG1yID0gJmZzbF9sYmNfcmVncy0+bWFtcjsNCj4gPiA+ID4gKwkJdXBtLT5teG1yID0gJmZzbF9s
YmNfY3RybF9kZXYtPnJlZ3MtPm1hbXI7DQo+ID4gPg0KPiA+ID4gRGl0dG8sIGEgdmVyeSByZXBl
dGl0aXZlIHN0dWZmLCBkZXNpcmVzIGEgdmFyaWFibGUgZm9yIHJlZ3M/DQo+ID4gQnV0IHRoZSBm
YWN0IGlzIHRoYXQgdGhlIHZhcmlhYmxlIHJlcHJlc2VudHMgZGlmZmVyZW50IHJlZw0KPiA+IGFk
ZHJlc3MgYWNjb3JkaW5nIHRvIHRoZSBjb25kaXRpb24uIEl0IHdpbGwgYmUgdWdseSB0byB1c2UN
Cj4gPiB0aGUgcmVnIGFkZHJlc3MgZGlyZWN0b2x5Lg0KPiANCj4gSSBtZWFudCBhIGRlZGljYXRl
ZCB2YXIgZm9yICdmc2xfbGJjX2N0cmxfZGV2LT5yZWdzJy4NCj4gSS5lLg0KPiANCj4gcmVncyA9
IGZzbF9sYmNfY3RybF9kZXYtPnJlZ3M7DQo+IC4uLg0KPiBteG1yID0gJnJlZ3MtPm1hbXI7DQo+
IC4uLg0KPiBteG1yID0gJnJlZ3MtPm1ibXI7DQo+IC4uDQo+IG14bXIgPSAmcmVncy0+bWNtcjsN
Cj4gDQo+IEluc3RlYWQgb2YNCj4gDQo+IG14bXIgPSAmZnNsX2xiY19jdHJsX2Rldi0+cmVncy0+
bWFtcjsNCj4gLi4uDQo+IG14bXIgPSAmZnNsX2xiY19jdHJsX2Rldi0+cmVncy0+bWJtcjsNCj4g
Li4NCj4gbXhtciA9ICZmc2xfbGJjX2N0cmxfZGV2LT5yZWdzLT5tY21yOw0KVGhhdCBtYWtlcyBz
ZW5zZS4gIEEgZ2xvYmFsIG9yIGxvY2FsIHZhcmlhYmxlIGZvciBmc2xfbGJjX2N0cmxfZGV2LT5y
ZWdzPyBXaGljaCBvbmUgaXMgYmV0dGVyPw0KDQo+IA0KPiBbLi4uXQ0KPiA+ID4gPiArc3RhdGlj
IGludCBfX2RldmluaXQgZnNsX2xiY19jdHJsX3Byb2JlKHN0cnVjdCBvZl9kZXZpY2UgKm9mZGV2
LA0KPiA+ID4gPiArCQkJCQkgY29uc3Qgc3RydWN0IG9mX2RldmljZV9pZCAqbWF0Y2gpDQo+ID4g
PiA+ICt7DQo+ID4gPiA+ICsJaW50IHJldCA9IDA7DQo+ID4gPg0KPiA+ID4gbm8gbmVlZCBmb3Ig
dGhlIGluaXRpYWwgdmFsdWUgaGVyZS4NCj4gPiBBbnkgaGFybT8NCj4gDQo+IFByb2JhYmx5IG5v
dCBhcyBnY2Mgd2lsbCBsaWtlbHkgb3B0aW1pemUgaXQgYXdheSwNCj4gYnV0IGl0J3Mgbm90IG5l
ZWRlZCwgc28gd2h5IGtlZXAgaXQgdGhlcmU/DQpoYWJpdC4NClRoYW5rcy4NClJveQ0KDQo=
^ permalink raw reply
* Re: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Anton Vorontsov @ 2010-09-06 9:44 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A1B3872@zch01exm23.fsl.freescale.net>
On Mon, Sep 06, 2010 at 05:24:35PM +0800, Zang Roy-R61911 wrote:
[..]
> > mxmr = &fsl_lbc_ctrl_dev->regs->mcmr;
> That makes sense. A global or local variable for fsl_lbc_ctrl_dev->regs? Which one is better?
The less global variables, the better. So, I'd vote for
a local one.
> > [...]
> > > > > +static int __devinit fsl_lbc_ctrl_probe(struct of_device *ofdev,
> > > > > + const struct of_device_id *match)
> > > > > +{
> > > > > + int ret = 0;
> > > >
> > > > no need for the initial value here.
> > > Any harm?
> >
> > Probably not as gcc will likely optimize it away,
> > but it's not needed, so why keep it there?
> habit.
;-)
Thanks,
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* RE: [PATCH 1/3][MTD] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Zang Roy-R61911 @ 2010-09-06 10:15 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Wood Scott-B07421, Lan Chunhe-B25806, linuxppc-dev, linux-mtd,
akpm, Gala Kumar-B11780
In-Reply-To: <20100906094414.GA27034@oksana.dev.rtsoft.ru>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQW50b24gVm9yb250c292
IFttYWlsdG86Y2JvdWF0bWFpbHJ1QGdtYWlsLmNvbV0NCj4gU2VudDogTW9uZGF5LCBTZXB0ZW1i
ZXIgMDYsIDIwMTAgMTc6NDQgUE0NCj4gVG86IFphbmcgUm95LVI2MTkxMQ0KPiBDYzogbGludXgt
bXRkQGxpc3RzLmluZnJhZGVhZC5vcmc7IExhbiBDaHVuaGUtQjI1ODA2OyBsaW51eHBwYy1kZXZA
b3psYWJzLm9yZzsNCj4gYWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZzsgR2FsYSBLdW1hci1CMTE3
ODA7IFdvb2QgU2NvdHQtQjA3NDIxDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS8zXVtNVERdIFA0
MDgwL2VMQkM6IE1ha2UgRnJlZXNjYWxlIGVsYmMgaW50ZXJydXB0IGNvbW1vbg0KPiB0byBlbGJj
IGRldmljZXMNCj4gDQo+IE9uIE1vbiwgU2VwIDA2LCAyMDEwIGF0IDA1OjI0OjM1UE0gKzA4MDAs
IFphbmcgUm95LVI2MTkxMSB3cm90ZToNCj4gWy4uXQ0KPiA+ID4gbXhtciA9ICZmc2xfbGJjX2N0
cmxfZGV2LT5yZWdzLT5tY21yOw0KPiA+IFRoYXQgbWFrZXMgc2Vuc2UuICBBIGdsb2JhbCBvciBs
b2NhbCB2YXJpYWJsZSBmb3IgZnNsX2xiY19jdHJsX2Rldi0+cmVncz8NCj4gV2hpY2ggb25lIGlz
IGJldHRlcj8NCj4gDQo+IFRoZSBsZXNzIGdsb2JhbCB2YXJpYWJsZXMsIHRoZSBiZXR0ZXIuIFNv
LCBJJ2Qgdm90ZSBmb3INCj4gYSBsb2NhbCBvbmUuDQpJIGFsc28gcHJlZmVyIGxvY2FsIG9uZS4N
Cj4gDQo+ID4gPiBbLi4uXQ0KPiA+ID4gPiA+ID4gK3N0YXRpYyBpbnQgX19kZXZpbml0IGZzbF9s
YmNfY3RybF9wcm9iZShzdHJ1Y3Qgb2ZfZGV2aWNlICpvZmRldiwNCj4gPiA+ID4gPiA+ICsJCQkJ
CSBjb25zdCBzdHJ1Y3Qgb2ZfZGV2aWNlX2lkICptYXRjaCkNCj4gPiA+ID4gPiA+ICt7DQo+ID4g
PiA+ID4gPiArCWludCByZXQgPSAwOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gbm8gbmVlZCBmb3Ig
dGhlIGluaXRpYWwgdmFsdWUgaGVyZS4NCj4gPiA+ID4gQW55IGhhcm0/DQo+ID4gPg0KPiA+ID4g
UHJvYmFibHkgbm90IGFzIGdjYyB3aWxsIGxpa2VseSBvcHRpbWl6ZSBpdCBhd2F5LA0KPiA+ID4g
YnV0IGl0J3Mgbm90IG5lZWRlZCwgc28gd2h5IGtlZXAgaXQgdGhlcmU/DQo+ID4gaGFiaXQuDQo+
IA0KPiA7LSkNCjotKC4NClRoYW5rcyBmb3IgYWxsIHlvdXIgY29tbWVudHMuIFRoYXQgaXMgdmFs
dWFibGUuDQpJIHdpbGwgdXBkYXRlIHRoZSBwYXRjaCBhY2NvcmRpbmcgdG8geW91ciBjb21tZW50
IGFuZCB0aGUgbmV3IHBsYXRmb3JtIGRldmljZSBhcmNoLg0KUm95DQo=
^ permalink raw reply
* Re: How to define an I2C-to-SPI bridge device ?
From: Andre Schwarz @ 2010-09-06 11:40 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <20100903120858.GA19380@oksana.dev.rtsoft.ru>
Anton,
> we're about to get new MPC8377 based hardware with various peripherals.
>> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
>> how to define a proper dts...
>>
>> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
>> device - but how can I represent the created SPI bus ?
> Um.. the same as the other SPI buses? I.e.
>
> i2c-controller { /* SOC I2C controller */
> spi-controller { /* The I2C-to-SPI bridge */
> spi-device@0 {
> };
> spi-device@1 {
> };
> };
> };
>
ok , thanks - looks straight forward.
Is this any more than plain definition, i.e. will this trigger any I2C
or SPI device registration/linking ?
>> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
>> I2C slave or an SPI host driver ?
> It should be an I2C driver that registers an SPI master (i.e.
> calls spi_alloc_master() and spi_register_master()).
hmm - ok. Will have to do it manually then ...
I still wonder how to make the driver arch-generic *and* of-capable.
Do we need a generic I2C slave driver that can be probed along with an
"of glue driver" or should the of-binding be part of a single device
driver ?
Sorry for the dumb questions - looks like I expected a little too much
functionality already existing.
Regards,
André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
^ permalink raw reply
* pci_request_regions() failure
From: Ravi Gupta @ 2010-09-06 12:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4100 bytes --]
Hi,
I am facing a problem while requesting pci resource. I have some data that I
am hopeful will help address the issue.
I am currently running on a MPC837xERDB board(powerpc) with a 2.6.35 kernel.
The problem is that whenever I insert the card (LatticeECP2M PCI Express
Development Kit<http://www.latticesemi.com/products/developmenthardware/developmentkits/pciexpressdevkitecp2m/index.cfm>)
in pci-express slot 0 and try to load my driver module, I get a
pci_request_regions() failure(error -EBUSY). The interesting thing is the
region that it fails for. According to /proc/iomem, slot0 has
a8000000-b7ffffff as its memory ranges. However, the memory region requested
by my device is a8000000-a803ffff and a8040000-a807ffff which falls in the
slot0 range. But after boot up when I look at /proc/iomem, there is a
already allocated resource range present there, which overlaps with the
range refined in my device, hence the pci_request_regions() fails.
Output of lspci
0000:00:00.0 Power PC: Freescale Semiconductor Inc Unknown device 00c6 (rev
21)
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc Unknown device 00c6
(rev 21)
0001:02:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Unknown device e250 ---> My device
Contents of /pro/iomem file
# cat /proc/iomem
80000000-8fffffff : /pci@e0008500
90000000-9fffffff : /pci@e0008500
a8000000-b7ffffff : /pcie@e0009000
a8000000-a80fffff : PCI Bus 0001:02 ---> colprit range
c8000000-d7ffffff : /pcie@e000a000
e0004500-e0004507 : serial
e0004600-e0004607 : serial
e0023000-e0023fff : usb
Now my doubt is, who is allocating this range and why? It seem to me a
kernel bug as I also tried my device on i386 machine(opensuse, linux 2.6.35
i.e the same kernel version on powerpc board) and there everything works
fine. I don't know where to start to fix it. Please suggest.
Output of lspci
scooby:~ # lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM
Controller (rev 10)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express
Root Port (rev 10)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 10)
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition
Audio Controller (rev 01)
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
1 (rev 01)
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
2 (rev 01)
00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port
3 (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #3 (rev 01)
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI
Controller #4 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI
Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1)
00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface
Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller
(rev 01)
00:1f.2 IDE interface: Intel Corporation 82801GB/GR/GH (ICH7 Family) SATA
IDE Controller (rev 01)
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev
01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B
PCI Express Gigabit Ethernet controller (rev 01)
04:00.0 Non-VGA unclassified device: Lattice Semiconductor Corporation
Device e250 ----------> My device
05:06.0 Serial controller: Device 4348:3253 (rev 10)
Contents of /proc/iomem on i386 machine
cat /proc/iomem
.
.
.
fe900000-fe9fffff : PCI Bus 0000:04
fe900000-fe93ffff : 0000:04:00.0 ------------->My device
fe940000-fe97ffff : 0000:04:00.0 ------------->My device
fea00000-feafffff : PCI Bus 0000:03
fea00000-fea1ffff : 0000:03:00.0
fea20000-fea20fff : 0000:03:00.0
fea20000-fea20fff : r8169
.
.
.
Regards,
Ravi
[-- Attachment #2: Type: text/html, Size: 4529 bytes --]
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Josh Boyer @ 2010-09-06 14:15 UTC (permalink / raw)
To: Tirumala Marri; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <01bb9090932e6984c887273078fd586f@mail.gmail.com>
On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
>>
>> Then the device tree identifier, and the cpu setup functions, etc,
>> should indicate
>> 464, not APM821xx.
>This is new SoC based on 464 cpu core. All the previous SoC device tree
>CPU portion uses SoC name.
>
>>
>> Also, why add yet another defconfig? Isn't the eval board similar to
>> many others and can be supported with just a tweak of some existing
>> common defconfig instead?
>>
>Every new board needs new defconfig. And it is not same as others. It has
>Different features from other.
You make it sound as if that is a hard and fixed rule. It's not. Not all
boards need a defconfig. Also, there was recent work to trim the defconfigs
that exist today down so they are not so large. I suggest you do the same
if you want the defconfig included.
josh
^ permalink raw reply
* [PATCH 00/14] Removing dead code
From: Christian Dietrich @ 2010-09-06 14:35 UTC (permalink / raw)
To: Lennert Buytenhek, Russell King, Yoshinori Sato, Kyle McMartin,
Helge Deller, James E.J. Bottomley, Akinobu Mita,
Benjamin Herrenschmidt, Paul Mackerras, Alexander Graf, K.Prasad,
Dave Kleikamp, Martin Schwidefsky, Heiko Carstens, linux390,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Borislav Petkov, David S. Miller, Roland Dreier, Alexey Dobriyan,
Joe Perches, Juergen E. Fischer, Tejun Heo, Krzysztof Helt,
Andrew Morton, Geert Uytterhoeven, Petr Vandrovec, Jean Delvare,
Arnaldo Carvalho de Melo, Eric W. Biederman, Ben Hutchings,
Cyrill Gorcunov, Peter Zijlstra, Mike Galbraith, Dipankar Sarma,
Paul E. McKenney, Josh Triplett, Lai Jiangshan, linux-arm-kernel,
linux-kernel, linux-parisc, linuxppc-dev, linux-s390, netdev,
linux-scsi, linux-fbdev
Cc: vamos-dev
Hi all!
As part of the VAMOS[0] research project at the University of Erlangen
we are looking at multiple integrity errors in linux' configuration
system.
I've been running a check on the whole sourcetree for
code block which are undead. This means they can't be deselected and
are always in the kernel if the enviroment of the block is
selected. They have often the form of
#ifdef ABC
....
#ifdef ABC
fooooo
#endif
#endif
Here the ifdefs of the inner block can be removed without any harm. At
this point we just checked the source code (for the undead), but we
want to do a crosscheck with the Kconfig for undead code blocks in the
future.
I build the patches against a vanilla kernel (v2.6.36-rc3) in order to
try if the kernel compiles with this patches.
Please keep me informed of this patch getting confirmed / merged so we
can keep track of it.
Regards
Christian Dietrich
[0] http://vamos1.informatik.uni-erlangen.de/
Christian Dietrich (14):
arch/arm: Removing undead ifdef __ASSEMBLY__
arch/h8300: Removing dead ifdef __H8300_TLB_H__
arch/parisc: Removing undead ifdef CONFIG_PA20
arch/{s390,powerpc}: Removing undead ifdef __KERNEL__
arch/x86: Removing undead ifdef ACPI/X86_IO_ACPI
drivers/net: Removing undead ifdef CHELSIO_T1_1G
drivers/scsi: Removing undead ifdef __ISAPNP__
drivers/scsi: Removing undead ifdef CONFIG_PCI
drivers/scsi: Removing undead ifdef REAL_DMA
drivers/video: Removing undead ifdef ATAFB_FALCON
drivers/video: Removing undead ifdef CONFIG_FB_MATROX_G
include/linux: Removing undead ifdef __KERNEL__
kernel/: Removing undead ifdef CONFIG_SMP
kernel/: Removing undead ifdef CONFIG_DEBUG_LOCK_ALLOC
arch/arm/mach-ixp23xx/include/mach/platform.h | 3 ---
arch/h8300/include/asm/tlb.h | 13 -------------
arch/parisc/kernel/unaligned.c | 3 ---
arch/powerpc/include/asm/processor.h | 2 --
arch/powerpc/include/asm/vdso_datapage.h | 2 --
arch/s390/include/asm/processor.h | 4 ----
arch/x86/kernel/early-quirks.c | 2 --
drivers/net/chelsio/subr.c | 2 --
drivers/scsi/aha152x.c | 2 --
drivers/scsi/aic7xxx_old.c | 2 --
drivers/scsi/atari_NCR5380.c | 6 ------
drivers/video/atafb.c | 2 --
drivers/video/matrox/matroxfb_DAC1064.c | 5 +----
include/linux/socket.h | 6 +-----
kernel/sched.c | 4 +---
kernel/srcu.c | 2 --
16 files changed, 3 insertions(+), 57 deletions(-)
^ permalink raw reply
* [PATCH 04/14] arch/{s390,powerpc}: Removing undead ifdef __KERNEL__
From: Christian Dietrich @ 2010-09-06 14:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Alexander Graf, K.Prasad,
Dave Kleikamp, Martin Schwidefsky, Heiko Carstens, linux390,
linuxppc-dev, linux-kernel, linux-s390
Cc: vamos-dev
In-Reply-To: <cover.1283782698.git.qy03fugy@stud.informatik.uni-erlangen.de>
The __KERNEL__ ifdef isn't necessary at this point, because it is
checked in an outer ifdef level already and has no effect here.
Signed-off-by: Christian Dietrich <qy03fugy@stud.informatik.uni-erlangen.de>
---
arch/powerpc/include/asm/processor.h | 2 --
arch/powerpc/include/asm/vdso_datapage.h | 2 --
arch/s390/include/asm/processor.h | 4 ----
3 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 19c05b0..3defd7a 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -122,7 +122,6 @@ extern struct task_struct *last_task_used_spe;
TASK_UNMAPPED_BASE_USER32 : TASK_UNMAPPED_BASE_USER64 )
#endif
-#ifdef __KERNEL__
#ifdef __powerpc64__
#define STACK_TOP_USER64 TASK_SIZE_USER64
@@ -139,7 +138,6 @@ extern struct task_struct *last_task_used_spe;
#define STACK_TOP_MAX STACK_TOP
#endif /* __powerpc64__ */
-#endif /* __KERNEL__ */
typedef struct {
unsigned long seg;
diff --git a/arch/powerpc/include/asm/vdso_datapage.h b/arch/powerpc/include/asm/vdso_datapage.h
index 08679c5..25e3922 100644
--- a/arch/powerpc/include/asm/vdso_datapage.h
+++ b/arch/powerpc/include/asm/vdso_datapage.h
@@ -116,9 +116,7 @@ struct vdso_data {
#endif /* CONFIG_PPC64 */
-#ifdef __KERNEL__
extern struct vdso_data *vdso_data;
-#endif
#endif /* __ASSEMBLY__ */
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 73e2598..0e2a436 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -52,8 +52,6 @@ extern int get_cpu_capability(unsigned int *);
#endif /* __s390x__ */
-#ifdef __KERNEL__
-
#ifndef __s390x__
#define STACK_TOP (1UL << 31)
#define STACK_TOP_MAX (1UL << 31)
@@ -63,8 +61,6 @@ extern int get_cpu_capability(unsigned int *);
#endif /* __s390x__ */
-#endif
-
#define HAVE_ARCH_PICK_MMAP_LAYOUT
typedef struct {
--
1.7.0.4
^ permalink raw reply related
* Re: How to define an I2C-to-SPI bridge device ?
From: André Schwarz @ 2010-09-06 14:37 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: LinuxPPC List, DevTreeDiscuss
In-Reply-To: <4C84D334.6060008@matrix-vision.de>
Anton,
looks like I should have looked at include/spi/spi.h earlier :
/*
* INTERFACES between SPI master-side drivers and SPI infrastructure.
* (There's no SPI slave support for Linux yet...)
*/
...this is what I've been looking for.
thanks for your help and sorry for the noise.
Regards,
André
On Mon, 2010-09-06 at 13:40 +0200, Andre Schwarz wrote:
> Anton,
>
> > we're about to get new MPC8377 based hardware with various peripherals.
> >> There are two I2C-to-SPI bridge devices (NXP SC18IS602) and I'm not sure
> >> how to define a proper dts...
> >>
> >> Of course it's an easy thing creating 2 child nodes on the CPU's I2C
> >> device - but how can I represent the created SPI bus ?
> > Um.. the same as the other SPI buses? I.e.
> >
> > i2c-controller { /* SOC I2C controller */
> > spi-controller { /* The I2C-to-SPI bridge */
> > spi-device@0 {
> > };
> > spi-device@1 {
> > };
> > };
> > };
> >
> ok , thanks - looks straight forward.
> Is this any more than plain definition, i.e. will this trigger any I2C
> or SPI device registration/linking ?
> >> Is the (possibly) required driver (of_sc18is60x_spi ?) supposed to be an
> >> I2C slave or an SPI host driver ?
> > It should be an I2C driver that registers an SPI master (i.e.
> > calls spi_alloc_master() and spi_register_master()).
> hmm - ok. Will have to do it manually then ...
>
> I still wonder how to make the driver arch-generic *and* of-capable.
> Do we need a generic I2C slave driver that can be probed along with an
> "of glue driver" or should the of-binding be part of a single device
> driver ?
>
> Sorry for the dumb questions - looks like I expected a little too much
> functionality already existing.
>
>
> Regards,
> André
>
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich
^ permalink raw reply
* RE: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Tirumala Marri @ 2010-09-06 14:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20100906141513.GA15942@hansolo.jdub.homelinux.org>
> >Every new board needs new defconfig. And it is not same as others. It
> has
> >Different features from other.
>
> You make it sound as if that is a hard and fixed rule. It's not. Not
> all
> boards need a defconfig. Also, there was recent work to trim the
> defconfigs
> that exist today down so they are not so large. I suggest you do the
> same
> if you want the defconfig included.
[Marri] Mr Josh sure let me take a look at it
-Marri
^ permalink raw reply
* Re: [PATCH] APM821xx: Add support for new SoC APM821xx
From: Olof Johansson @ 2010-09-06 15:45 UTC (permalink / raw)
To: Tirumala Marri; +Cc: linuxppc-dev
In-Reply-To: <01bb9090932e6984c887273078fd586f@mail.gmail.com>
On Sun, Sep 05, 2010 at 10:19:53PM -0700, Tirumala Marri wrote:
> >
> > Then the device tree identifier, and the cpu setup functions, etc,
> > should indicate
> > 464, not APM821xx.
> This is new SoC based on 464 cpu core. All the previous SoC device tree
> CPU portion uses SoC name.
Hm, you're right. Confusing.
Still, the cpu setup functions would make more sense to have the core
name in, not the SoC name. Especially since multiple SoC families might
use the same core, etc.
> > Also, why add yet another defconfig? Isn't the eval board similar to
> > many others and can be supported with just a tweak of some existing
> > common defconfig instead?
> >
> Every new board needs new defconfig. And it is not same as others. It has
> Different features from other.
Actually, it doesn't. Linus has had a strong pushback to the ARM community
because of this mentality. arch/powerpc already has 100 defconfigs.
The use of devicetrees means that only the actual devices on your board,
will be configured, so it doesn't do any damage to compile in more drivers
than you happen to have. Thus generating a defconfig that is a superset
of some of your more common boards, or for example one per family of boards.
One of the arguments for having custom defconfigs per board is that customers that
base designs off of your eval board needs them. But they will make other changes
to the config to add drivers for whatever additional devices they have anyway.
-Olof
^ 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