Re: [PATCH/RFC] 64 bit csum_partial_copy_generic

[Paul Mackerras]

Joel Schopp writes:

 As for the technical comments, I agree with all of them and will 
 incorporate them into the next version.

Mark Nelson is working on new memcpy and __copy_tofrom_user routines
that look like they will be simpler than the old ones as well as being
faster, particularly on Cell.  It turns out that doing unaligned
8-byte loads is faster than doing aligned loads + shifts + ors on
POWER5 and later machines.  So I suggest that you try a loop that does
say 4 ld's and 4 std's rather than worrying with all the complexity of
the shifts and ors.  On POWER3, ld and std that are not 4-byte aligned
will cause an alignment interrupt, so there I suggest we fall back to
just using lwz and stw as at present (though maybe with the loop
unrolled a bit more).  We'll be adding a feature bit to tell whether
the cpu can do unaligned 8-bytes loads and stores without trapping.

Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Dan Williams]

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
  drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
  drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
  'cpuid_eax'
  drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
  drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
  'boot_cpu_has'
  drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
  in this function)
  drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
  only once
  drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
  drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
  drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
  'cpu_physical_id'
 
 Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run in
 order to fix this, but he hasn't shown any signs of life.
 
 So I'll do it myself later tonight. :-/
 
The following seems to fix this up...

---snip---
ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y

From: Dan Williams [EMAIL PROTECTED]

The INTEL_IOATDMA symbol depends on x86. 'select' ignores this
dependency.

Cc: Brice Goglin [EMAIL PROTECTED]
Cc: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Dan Williams [EMAIL PROTECTED]
---

 drivers/net/Kconfig |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 1d8af33..84983f8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2410,7 +2410,7 @@ config IXGBE
tristate Intel(R) 10GbE PCI Express adapters support
depends on PCI  INET
select INET_LRO
-   select INTEL_IOATDMA
+   select INTEL_IOATDMA if X86
---help---
  This driver supports Intel(R) 10GbE PCI Express family of
  adapters.  For more information on how to identify your adapter, go
@@ -2462,7 +2462,7 @@ config MYRI10GE
select FW_LOADER
select CRC32
select INET_LRO
-   select INTEL_IOATDMA
+   select INTEL_IOATDMA if X86
---help---
  This driver supports Myricom Myri-10G Dual Protocol interface in
  Ethernet mode. If the eeprom on your board is not recent enough,


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Brice Goglin]

Dan Williams wrote:
 On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
   
 drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
 drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
 'cpuid_eax'
 drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
 drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
 'boot_cpu_has'
 drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
 in this function)
 drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
 only once
 drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
 drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
 drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
 'cpu_physical_id'
   
 Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run in
 order to fix this, but he hasn't shown any signs of life.

 So I'll do it myself later tonight. :-/

 
 The following seems to fix this up...

 ---snip---
 ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y
   

There's already a completely different fix queued in netdev patchworks
(for myri10ge only right now, to be duplicated for Intel drivers). The
idea is to stop having almost-unrelated drivers select each other
directly, let people select which drivers they really want, and have
Kconfig handle modules/builtin-stuff correctly. See
http://patchwork.ozlabs.org/patch/4506/

Brice

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[David Miller]

From: Brice Goglin [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 08:55:08 +0200

 Dan Williams wrote:
  On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:

  drivers/dma/ioat_dca.c: In function 'dca_enabled_in_bios':
  drivers/dma/ioat_dca.c:81: error: implicit declaration of function 
  'cpuid_eax'
  drivers/dma/ioat_dca.c: In function 'system_has_dca_enabled':
  drivers/dma/ioat_dca.c:91: error: implicit declaration of function 
  'boot_cpu_has'
  drivers/dma/ioat_dca.c:91: error: 'X86_FEATURE_DCA' undeclared (first use 
  in this function)
  drivers/dma/ioat_dca.c:91: error: (Each undeclared identifier is reported 
  only once
  drivers/dma/ioat_dca.c:91: error: for each function it appears in.)
  drivers/dma/ioat_dca.c: In function 'ioat_dca_get_tag':
  drivers/dma/ioat_dca.c:190: error: implicit declaration of function 
  'cpu_physical_id'

  Known issue.  I tried to ping Jeff Garzik about doing a driver bug fix run 
  in
  order to fix this, but he hasn't shown any signs of life.
 
  So I'll do it myself later tonight. :-/
 
  
  The following seems to fix this up...
 
  ---snip---
  ixgbe, myri10ge: INTEL_IOATDMA can only be selected when X86=y

 
 There's already a completely different fix queued in netdev patchworks
 (for myri10ge only right now, to be duplicated for Intel drivers). The
 idea is to stop having almost-unrelated drivers select each other
 directly, let people select which drivers they really want, and have
 Kconfig handle modules/builtin-stuff correctly. See
 http://patchwork.ozlabs.org/patch/4506/

Right, my plan was to duplicate this for the other drivers.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Takashi Iwai]

At Thu, 16 Oct 2008 10:38:36 +0300,
Adrian Bunk wrote:
 
 On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
  At Wed, 15 Oct 2008 21:33:37 -0700,
  Andrew Morton wrote:
   
   sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
   deprecated (declared at sound/soc/soc-dapm.c:1026)
   sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
   deprecated (declared at sound/soc/soc-dapm.c:1026)
  
  These are definitions of deprecated interfaces.
  We can remove it in 2.6.29.  If we don't want to be conservative, it
  can be removed in 2.6.28, too.
 ...
 
 Since it's an in-kernel API there's no reason to keep it once there are 
 no users left.

Right.  But, IMO, now is no suitable time.
A thing like API removal should have been tested in linux-next, and we
had plenty of time indeed for 2.6.28.

 But currently sound/soc/at32/playpaq_wm8510.c still seems to use it.

Yep, but don't be bothered to try to create a patch for that.
There will be a unification patch for both at32 and at91, so clean-ups
will be applied anyway later.


thanks,

Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems with PCI-E devices not being detected with switch

[Stefan Roese]

On Thursday 16 October 2008, Benjamin Herrenschmidt wrote:
  pci 0001:02:1c.0: ignoring class 5d01 (doesn't match header type 02)
  pci 0001:02:1d.0: unknown header type 41, ignoring device
  pci 0001:02:1e.0: unknown header type 03, ignoring device
  pci 0001:02:1f.0: unknown header type 41, ignoring device

 Stefan, do you reckon it could be that we aren't leaving enough time
 for the things behind the switch to initialize ? Or could there be
 a subtle kernel bug here ? It looks to me that config space
 access behind the switch is broken.

Yes, this could be possible. We (Ayman) should at least test with the delay as 
you mentioned below to see if this helps.

 Ayman, can you try adding a long delay (such as msleep(5000), ie 5s)
 at the beginning of pcibios_init() in arch/powerpc/kernel/pci_32.c ?
 This will add 5s delay between the init/reset of the port and the
 probing by linux. Do that help ?

 Stefan, shouldn't we find a nice way to avoid the whole port reset and
 reconfiguration of the HW also when uboot already did a good enough job,
 maybe via some device-tree property ? It would also significantly speed
 up boot times.

Doing this unconditionally is not a good idea since we could have an old 
(buggy) firmware which didn't configure the PCIe controller correctly. But I 
really like your idea with the device-tree property to optionally skip this 
re-configuration. Now we only need to find some volunteer to do this 
job... ;)

Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Geert Uytterhoeven]

On Wed, 15 Oct 2008, David Miller wrote:
  kernel/resource.c: In function '__reserve_region_with_split':
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 3 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 4 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 6 has type 'resource_size_t'
  kernel/resource.c:554: warning: format '%llx' expects type 'long long 
  unsigned int', but argument 7 has type 'resource_size_t'
 
 Known issue, Ben wants to add a new variant of %pX in order to print 
 resources so that
 resource_size_t vs. unsigned long stuff doesn't matter like this any more.

Will still give a warning, as resource_size_t is not a pointer.

  drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_read':
  drivers/rtc/rtc-ds1286.c:33: error: implicit declaration of function 
  '__raw_readl'
  drivers/rtc/rtc-ds1286.c: In function 'ds1286_rtc_write':
  drivers/rtc/rtc-ds1286.c:38: error: implicit declaration of function 
  '__raw_writel'
  drivers/rtc/rtc-ds1286.c: In function 'ds1286_probe':
  drivers/rtc/rtc-ds1286.c:345: error: implicit declaration of function 
  'ioremap'
  drivers/rtc/rtc-ds1286.c:345: warning: assignment makes pointer from 
  integer without a cast
  drivers/rtc/rtc-ds1286.c:365: error: implicit declaration of function 
  'iounmap'
 
 Missing asm/io.h include.

Nah, linux/io.h ;-)

  drivers/rtc/rtc-m48t35.c: In function 'm48t35_read_time':
  drivers/rtc/rtc-m48t35.c:59: error: implicit declaration of function 'readb'
  drivers/rtc/rtc-m48t35.c:60: error: implicit declaration of function 
  'writeb'
  drivers/rtc/rtc-m48t35.c: In function 'm48t35_probe':
  drivers/rtc/rtc-m48t35.c:168: error: implicit declaration of function 
  'ioremap'
  drivers/rtc/rtc-m48t35.c:168: warning: assignment makes pointer from 
  integer without a cast
  drivers/rtc/rtc-m48t35.c:188: error: implicit declaration of function 
  'iounmap'
 
 Likewise.

Already sent a patch for these two...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Geert Uytterhoeven]

On Thu, 16 Oct 2008, David Miller wrote:
 From: Geert Uytterhoeven [EMAIL PROTECTED]
 Date: Thu, 16 Oct 2008 09:31:29 +0200 (CEST)
 
  On Wed, 15 Oct 2008, David Miller wrote:
kernel/resource.c: In function '__reserve_region_with_split':
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 3 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 4 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 6 has type 'resource_size_t'
kernel/resource.c:554: warning: format '%llx' expects type 'long long 
unsigned int', but argument 7 has type 'resource_size_t'
   
   Known issue, Ben wants to add a new variant of %pX in order to print 
   resources so that
   resource_size_t vs. unsigned long stuff doesn't matter like this any more.
  
  Will still give a warning, as resource_size_t is not a pointer.
 
 The idea is to pass in a pointer to the resource struct,
 and the %pX variant specified says what part to print.

Neat! So we can also have a separate variant to print the resource
range.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Adrian Bunk]

On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
 At Thu, 16 Oct 2008 10:38:36 +0300,
 Adrian Bunk wrote:
  
  On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
   At Wed, 15 Oct 2008 21:33:37 -0700,
   Andrew Morton wrote:

sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
deprecated (declared at sound/soc/soc-dapm.c:1026)
sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
deprecated (declared at sound/soc/soc-dapm.c:1026)
   
   These are definitions of deprecated interfaces.
   We can remove it in 2.6.29.  If we don't want to be conservative, it
   can be removed in 2.6.28, too.
  ...
  
  Since it's an in-kernel API there's no reason to keep it once there are 
  no users left.
 
 Right.  But, IMO, now is no suitable time.
 A thing like API removal should have been tested in linux-next, and we
 had plenty of time indeed for 2.6.28.
...

A grep through the tree and one test compile that covers 
sound/soc/soc-dapm.c should be enough testing.

And having it then in -next once should be enough to discover if someone 
wrongly added a new user.

I have removed many functions in the kernel, and there isn't much that 
can go wrong - even adding a PCI ID to a driver has a bigger risk of 
introducing a regression.

 thanks,
 
 Takashi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Andreas Schwab]

David Miller [EMAIL PROTECTED] writes:

 net/dccp/options.c: In function 'dccp_parse_options':
 net/dccp/options.c:67: warning: 'value' may be used uninitialized in this 
 function

 Known issue, not trivial to fix, gcc is just being incredibly silly here as it
 can't see all of the control flow.

Seems to be fixed in gcc 4.3.  It actually needs a pretty complete value
tracking to get right.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Takashi Iwai]

At Thu, 16 Oct 2008 11:21:57 +0300,
Adrian Bunk wrote:
 
 On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
  At Thu, 16 Oct 2008 10:38:36 +0300,
  Adrian Bunk wrote:
   
   On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
At Wed, 15 Oct 2008 21:33:37 -0700,
Andrew Morton wrote:
 
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)

These are definitions of deprecated interfaces.
We can remove it in 2.6.29.  If we don't want to be conservative, it
can be removed in 2.6.28, too.
   ...
   
   Since it's an in-kernel API there's no reason to keep it once there are 
   no users left.
  
  Right.  But, IMO, now is no suitable time.
  A thing like API removal should have been tested in linux-next, and we
  had plenty of time indeed for 2.6.28.
 ...
 
 A grep through the tree and one test compile that covers 
 sound/soc/soc-dapm.c should be enough testing.
 
 And having it then in -next once should be enough to discover if someone 
 wrongly added a new user.

My point is the time for removal.  The API changes should have been
done in the merge window, and it should have been tested *before* the
merge window.

 I have removed many functions in the kernel, and there isn't much that 
 can go wrong - even adding a PCI ID to a driver has a bigger risk of 
 introducing a regression.

Yeah, IMHO, adding PCI IDs blindly at the late stage should be
avoided, too, although many people love that.


thanks,

Takashi
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems with PCI-E devices not being detected with switch

[Stefan Roese]

On Thursday 16 October 2008, Benjamin Herrenschmidt wrote:
 On Thu, 2008-10-16 at 10:03 +0200, Stefan Roese wrote:
  Doing this unconditionally is not a good idea since we could have an old
  (buggy) firmware which didn't configure the PCIe controller correctly.
  But I really like your idea with the device-tree property to optionally
  skip this re-configuration. Now we only need to find some volunteer to
  do this job... ;)

 I don't have a problem adding support for testing that property and
 skipping most of the initial HW setup, basically treating the endpoint
 as pre-configured.

 What about using a value for status ?

No. status is already used to disable/skip the PCIe slot completely. For 
example on Canyonlands where PCIe#0 is multiplexed with the SATA port.

 Or an empty configured 
 property ? Ideally, it should have been the other way around, ie
 unconfigured for old/buggy stuff but I'm worried there may be existing
 out-of-tree device-trees without it :-)

Yeah. I could add this configured property to the current U-Boot version. 
Perhaps we should add some version information to it so that Linux could 
eventually decide to re-configure when the configured version is known to 
be buggy. What do you think?

Best regards,
Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems with PCI-E devices not being detected with switch

[Benjamin Herrenschmidt]

On Thu, 2008-10-16 at 10:48 +0200, Stefan Roese wrote:
 Yeah. I could add this configured property to the current U-Boot version. 
 Perhaps we should add some version information to it so that Linux could 
 eventually decide to re-configure when the configured version is known to 
 be buggy. What do you think?

I'd rather have the platform have a way to override it rather than
having tests for uboot versions in the pci code itself.

Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: Problems with PCI-E devices not being detected with switch

[Benjamin Herrenschmidt]

On Thu, 2008-10-16 at 10:03 +0200, Stefan Roese wrote:
 Doing this unconditionally is not a good idea since we could have an old 
 (buggy) firmware which didn't configure the PCIe controller correctly. But I 
 really like your idea with the device-tree property to optionally skip this 
 re-configuration. Now we only need to find some volunteer to do this 
 job... ;)

I don't have a problem adding support for testing that property and
skipping most of the initial HW setup, basically treating the endpoint
as pre-configured.

What about using a value for status ? Or an empty configured
property ? Ideally, it should have been the other way around, ie
unconfigured for old/buggy stuff but I'm worried there may be existing
out-of-tree device-trees without it :-)

Cheers,
Ben

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ehea: Fix memory hotplug support

[Jeff Garzik]

Hannes Hering wrote:

This patch implements the memory notifier to update the busmap instantly
instead of rebuilding the whole map. This is necessary because
walk_memory_resource provides different information than required during memory
hotplug.

Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---
This patch is based on the current netdev-2.6-git. It supersedes the previous
post ehea: Fix memory hotplug support.
http://www.spinics.net/lists/netdev/msg75413.html


Due to vacation, netdev-2.6.git is stale.  Please regenerate this patch 
against davem's net-2.6.git.


Jeff



___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

linux-next: build failure

[Stephen Rothwell]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
 from arch/powerpc/include/asm/mmu.h:8,
 from arch/powerpc/include/asm/pgtable.h:8,
 from arch/powerpc/mm/slb.c:20:
arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'memstart_addr'
arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'kernstart_addr'

Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 (generic: add
phys_addr_t for holding physical addresses) from the tip-core tree.
This only fails if CONFIG_RELOCATABLE is set.

I have applied the patch below.
-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/

From 3e3a6a5f9479a4d35070c15f863a8635e9865058 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 20:07:00 +1100
Subject: [PATCH] tip-core/powerpc: phys_addr_t has moved to linux/types.h

So include that instead of asm/types.h in asm/page.h for
the CONFIG_RELOCATABLE case.

Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
 arch/powerpc/include/asm/page.h |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 64e1445..5ac51e6 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -10,9 +10,13 @@
  * 2 of the License, or (at your option) any later version.
  */
 
+#ifndef __ASSEMBLY__
+#include linux/types.h
+#else
+#include asm/types.h
+#endif
 #include asm/asm-compat.h
 #include asm/kdump.h
-#include asm/types.h
 
 /*
  * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
-- 
1.5.6.5


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] tpm: don't export static functions

[Stephen Rothwell]

Today's linux-next build (powerpc_allyesconfig) failed like this:

drivers/char/tpm/tpm.c:1162: error: __ksymtab_tpm_dev_release causes a section 
type conflict

Caused by commit 253115b71fa06330bd58afbe01ccaf763a8a0cf1 (The
tpm_dev_release function is only called for platform devices, not pnp)
which exported a static function.

Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
 drivers/char/tpm/tpm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/char/tpm/tpm.c b/drivers/char/tpm/tpm.c
index 1fee703..f61c9fe 100644
--- a/drivers/char/tpm/tpm.c
+++ b/drivers/char/tpm/tpm.c
@@ -1150,7 +1150,7 @@ EXPORT_SYMBOL_GPL(tpm_dev_vendor_release);
  * Once all references to platform device are down to 0,
  * release all allocated structures.
  */
-static void tpm_dev_release(struct device *dev)
+void tpm_dev_release(struct device *dev)
 {
struct tpm_chip *chip = dev_get_drvdata(dev);
 
-- 
1.5.6.5

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] mfd/wm8350: don't export static functions

[Stephen Rothwell]

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache causes a 
section type conflict

Caused by commit 89b4012befb1abca5e86d232bc0e2a797b0d9825 (mfd: Core
support for the WM8350 AudioPlus PMIC). wm8350_create_cache is not used
elsewhere, so remove the EXPORT_SYMBOL.

Signed-off-by: Stephen Rothwell [EMAIL PROTECTED]
---
 drivers/mfd/wm8350-core.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/mfd/wm8350-core.c b/drivers/mfd/wm8350-core.c
index bf87f67..fbe22fb 100644
--- a/drivers/mfd/wm8350-core.c
+++ b/drivers/mfd/wm8350-core.c
@@ -1128,7 +1128,6 @@ static int wm8350_create_cache(struct wm8350 *wm8350, int 
mode)
 out:
return ret;
 }
-EXPORT_SYMBOL_GPL(wm8350_create_cache);
 
 /*
  * Register a client device.  This is non-fatal since there is no need to
-- 
1.5.6.5

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS

[Hendrik Brueckner]

Hello,

for the sake of completion, here are few more details why I have suggest to
add the TTY_DRIVER_RESET_TERMIOS flag:

On Tue, Oct 14, 2008 at 10:40:25AM +0100, Alan Cox wrote:
 On Tue, 14 Oct 2008 11:12:49 +0200
 Hendrik Brueckner [EMAIL PROTECTED] wrote:
 
  After a tty hangup() or close() operation, processes might not reset the
  termio settings to a sane state.
 That is the job of the getty task normally. pty is special as the reissue
 of the same pty is done as a new device (with new state).

During some testing, I have experienced that the bash alters few termios
settings before showing the bash prompt:
-
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
write(2, [EMAIL PROTECTED]:~# , 17) = 17
-
If the tty gets a hangup, the bash gets terminated but the settings still
remains after init has respawned the getty process.
For my network-based hvc backend, a tty_hangup() is caused by a disconnect.

I looked into the tty_io.c source and found out that the termios settings
are stored in an array of the tty driver struct and they remains unchanged
if a tty device is released and initialized again.
At tty device initialization, the tty_init_termios() set tty-termios to the
tty-driver-termios[tty-index].

The idea is to ensure that when a tty is initialized it has the
default (initial) termio settings; and that is actually done if
TTY_DRIVER_RESET_TERMIOS is set.

Anyhow the other possibility might be to always set the initial termios
when the tty is initialized (see patch below).
But I am not sure if that case is the general behavior of ttys.
Please let me know if there is a reason not to re-initialize the termios
of a new tty.

Thanks.

Best regards
Hendrik

Signed-off-by: Hendrik Brueckner [EMAIL PROTECTED]
---
 drivers/char/tty_io.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/char/tty_io.c 2008-10-16 09:48:00.0 +0200
+++ b/drivers/char/tty_io.c 2008-10-16 12:55:52.0 +0200
@@ -1243,10 +1243,9 @@ int tty_init_termios(struct tty_struct *
tp = kzalloc(sizeof(struct ktermios[2]), GFP_KERNEL);
if (tp == NULL)
return -ENOMEM;
-   memcpy(tp, tty-driver-init_termios,
-   sizeof(struct ktermios));
tty-driver-termios[idx] = tp;
}
+   memcpy(tp, tty-driver-init_termios, sizeof(struct ktermios));
tty-termios = tp;
tty-termios_locked = tp + 1;
 
-- 
Hendrik Brueckner
D/3303 Linux on System z Development
Tel: +49 7031 16-1073
Fax: +49 7031 16-3456
eMail: [EMAIL PROTECTED]
IBM Deutschland Research  Development GmbH, Schoenaicher Str. 220, 71032 
Boeblingen

IBM Deutschland Research  Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC PATCH 4/5] hvc_console: Add tty window resizing

[Christian Borntraeger]

Am Donnerstag, 16. Oktober 2008 schrieb Rusty Russell:
  The patch provides the hvc_resize() function to update the terminal
  window dimensions (struct winsize) for a specified hvc console.
  The function stores the new window size and schedules a function
  that finally updates the tty winsize and signals the change to
  user space (SIGWINCH).
  Because the winsize update must acquire a mutex and might sleep,
  the function is scheduled instead of being called from hvc_poll()
  or khvcd.
 
 I want this functionality for lguest, too.  But I don't see anything which 
 uses this call yet?   Are we going to use the config_change notifier from 
 virtio?  (Which IIRC neither S/390 nor lguest have plumbed in).

I have some prototype patches for virtio_console, but did not find the time to 
finish them.

Christian
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] i2c-cpm: Suppress autoprobing for devices

[Jochen Friedrich]

Wolfram Sang schrieb:
 Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove
 automatic probing for this i2c controller. Might need updates to dts files
 using it.
 
 Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
Acked-by: Jochen Friedrich [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] Enable enhanced functions for 8536 TSEC

[Jason Jin]

Signed-off-by: Jason Jin [EMAIL PROTECTED]
---
 arch/powerpc/boot/dts/mpc8536ds.dts |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts 
b/arch/powerpc/boot/dts/mpc8536ds.dts
index 93fdd99..dce2f65 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -180,7 +180,7 @@
enet0: [EMAIL PROTECTED] {
cell-index = 0;
device_type = network;
-   model = TSEC;
+   model = eTSEC;
compatible = gianfar;
reg = 0x24000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
@@ -193,7 +193,7 @@
enet1: [EMAIL PROTECTED] {
cell-index = 1;
device_type = network;
-   model = TSEC;
+   model = eTSEC;
compatible = gianfar;
reg = 0x26000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
-- 
1.5.4

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] mfd/wm8350: don't export static functions

[Mark Brown]

On Thu, Oct 16, 2008 at 08:47:54PM +1100, Stephen Rothwell wrote:
 Today's linux-next build (powerpc allyesconfig) failed like this:

 drivers/mfd/wm8350-core.c:1131: error: __ksymtab_wm8350_create_cache causes a 
 section type conflict

 Caused by commit 89b4012befb1abca5e86d232bc0e2a797b0d9825 (mfd: Core
 support for the WM8350 AudioPlus PMIC). wm8350_create_cache is not used
 elsewhere, so remove the EXPORT_SYMBOL.

Acked-by: Mark Brown [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Adrian Bunk]

On Thu, Oct 16, 2008 at 10:43:33AM +0200, Takashi Iwai wrote:
 At Thu, 16 Oct 2008 11:21:57 +0300,
 Adrian Bunk wrote:
  
  On Thu, Oct 16, 2008 at 09:57:11AM +0200, Takashi Iwai wrote:
   At Thu, 16 Oct 2008 10:38:36 +0300,
   Adrian Bunk wrote:

On Thu, Oct 16, 2008 at 07:57:29AM +0200, Takashi Iwai wrote:
 At Wed, 15 Oct 2008 21:33:37 -0700,
 Andrew Morton wrote:
  
  sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
  deprecated (declared at sound/soc/soc-dapm.c:1026)
  sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
  deprecated (declared at sound/soc/soc-dapm.c:1026)
 
 These are definitions of deprecated interfaces.
 We can remove it in 2.6.29.  If we don't want to be conservative, it
 can be removed in 2.6.28, too.
...

Since it's an in-kernel API there's no reason to keep it once there are 
no users left.
   
   Right.  But, IMO, now is no suitable time.
   A thing like API removal should have been tested in linux-next, and we
   had plenty of time indeed for 2.6.28.
  ...
  
  A grep through the tree and one test compile that covers 
  sound/soc/soc-dapm.c should be enough testing.
  
  And having it then in -next once should be enough to discover if someone 
  wrongly added a new user.
 
 My point is the time for removal.  The API changes should have been
 done in the merge window, and it should have been tested *before* the
 merge window.
...

My point is simply that compared to many other patches that weren't 
tested before the merge window, and that still get (for various reasons) 
into the tree, the removal of unused functions is extremely low-risk 
(assuming the patch creator knows what grep is and does a test compile 
of the changed code).

 thanks,
 
 Takashi

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC PATCH 2/5] hvc_console: Add tty driver flag TTY_DRIVER_RESET_TERMIOS

[Alan Cox]

 For my network-based hvc backend, a tty_hangup() is caused by a disconnect.

If it is network backed then you probably do want
TTY_DRIVER_TERMIOS_RESET. For a normal serial type port getty is supposed
to sort the terminal settings out. So in your case it sounds like
resetting it is the right thing to do.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [RFC PATCH 4/5] hvc_console: Add tty window resizing

[Rusty Russell]

On Tuesday 14 October 2008 20:12:51 Hendrik Brueckner wrote:
 From: Hendrik Brueckner [EMAIL PROTECTED]

 The patch provides the hvc_resize() function to update the terminal
 window dimensions (struct winsize) for a specified hvc console.
 The function stores the new window size and schedules a function
 that finally updates the tty winsize and signals the change to
 user space (SIGWINCH).
 Because the winsize update must acquire a mutex and might sleep,
 the function is scheduled instead of being called from hvc_poll()
 or khvcd.

I want this functionality for lguest, too.  But I don't see anything which 
uses this call yet?   Are we going to use the config_change notifier from 
virtio?  (Which IIRC neither S/390 nor lguest have plumbed in).

Cheers,
Rusty.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Support for relocatable kdump kernel

[Mohan Kumar M]

Paul Mackerras wrote:

Mohan Kumar M writes:


Support for relocatable kdump kernel



@@ -1401,9 +1414,21 @@ _STATIC(__after_prom_start)
beq 9f  /* have already put us at zero */
li  r6,0x100/* Start offset, the first 0x100 */
/* bytes were copied earlier.*/
-#ifdef CONFIG_RELOCATABLE
+
+#ifdef CONFIG_CRASH_DUMP


What tree is this patch against?  No tree that I can find has a line
saying #ifdef CONFIG_RELOCATABLE at that point.  Or is there a
prerequisite patch that I haven't seen yet?


Hi Paul,

My patch is based on your PATCH 5 of relocatable kernel patchset (which 
demonstrates kernel can be relocatable).


Do I need to resend the patch by generating the diff with your patch5 also?

Regards,
Mohan.

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] ibm_newemac: Fix new MAL feature handling

[Josh Boyer]

On Thu, Oct 16, 2008 at 03:56:50PM +1100, Benjamin Herrenschmidt wrote:
 drivers/net/ibm_newemac/mal.c: In function 'mal_txeob':
 drivers/net/ibm_newemac/mal.c:284: error: implicit declaration of function 
 'mtdcri'
 drivers/net/ibm_newemac/mal.c:284: error: 'SDR0' undeclared (first use in 
 this function)
 drivers/net/ibm_newemac/mal.c:284: error: (Each undeclared identifier is 
 reported only once
 drivers/net/ibm_newemac/mal.c:284: error: for each function it appears in.)
 drivers/net/ibm_newemac/mal.c:285: error: implicit declaration of function 
 'mfdcri'
 drivers/net/ibm_newemac/mal.c: In function 'mal_rxeob':
 drivers/net/ibm_newemac/mal.c:302: error: 'SDR0' undeclared (first use in 
 this function)

That's annoying, I'll have a look.

Support for new features needed by the PPC 405EZ boards
introduced some errors in the MAL and EMAC feature handling.
This broke 'allmodconfig' builds as CONFIG_PPC_DCR_NATIVE is
not set for those.

This patch fixes these errors by wrapping the code in the
appropriate #ifdefs.

Signed-off-by: Josh Boyer [EMAIL PROTECTED]

---

diff --git a/drivers/net/ibm_newemac/core.c b/drivers/net/ibm_newemac/core.c
index efcf21c..2ee2622 100644
--- a/drivers/net/ibm_newemac/core.c
+++ b/drivers/net/ibm_newemac/core.c
@@ -2604,8 +2604,16 @@ static int __devinit emac_init_config(struct 
emac_instance *dev)
if (of_device_is_compatible(np, ibm,emac-440ep) ||
of_device_is_compatible(np, ibm,emac-440gr))
dev-features |= EMAC_FTR_440EP_PHY_CLK_FIX;
-   if (of_device_is_compatible(np, ibm,emac-405ez))
+   if (of_device_is_compatible(np, ibm,emac-405ez)) {
+#ifdef CONFIG_IBM_NEW_EMAC_NO_FLOW_CONTROL
dev-features |= EMAC_FTR_NO_FLOW_CONTROL_40x;
+#else
+   printk(KERN_ERR %s: Flow control not disabled!\n,
+   np-full_name);
+   return -ENXIO;
+#endif
+   }
+
}
 
/* Fixup some feature bits based on the device tree */
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 1839d3f..ecf9798 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -280,9 +280,11 @@ static irqreturn_t mal_txeob(int irq, void *dev_instance)
mal_schedule_poll(mal);
set_mal_dcrn(mal, MAL_TXEOBISR, r);
 
+#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
(mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | 
ICINTSTAT_ICTX));
+#endif
 
return IRQ_HANDLED;
 }
@@ -298,9 +300,11 @@ static irqreturn_t mal_rxeob(int irq, void *dev_instance)
mal_schedule_poll(mal);
set_mal_dcrn(mal, MAL_RXEOBISR, r);
 
+#ifdef CONFIG_PPC_DCR_NATIVE
if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT))
mtdcri(SDR0, DCRN_SDR_ICINTSTAT,
(mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | 
ICINTSTAT_ICRX));
+#endif
 
return IRQ_HANDLED;
 }
@@ -572,9 +576,18 @@ static int __devinit mal_probe(struct of_device *ofdev,
goto fail;
}
 
-   if (of_device_is_compatible(ofdev-node, ibm,mcmal-405ez))
+   if (of_device_is_compatible(ofdev-node, ibm,mcmal-405ez)) {
+#if defined(CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT)  \
+   defined(CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR)
mal-features |= (MAL_FTR_CLEAR_ICINTSTAT |
MAL_FTR_COMMON_ERR_INT);
+#else
+   printk(KERN_ERR %s: Support for 405EZ not enabled!\n,
+   ofdev-node-full_name);
+   err = -ENODEV;
+   goto fail;
+#endif
+   }
 
mal-txeob_irq = irq_of_parse_and_map(ofdev-node, 0);
mal-rxeob_irq = irq_of_parse_and_map(ofdev-node, 1);

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] ehea: Fix memory hotplug support

[Hannes Hering]

This patch implements the memory notifier to update the busmap instantly
instead of rebuilding the whole map. This is necessary because
walk_memory_resource provides different information than required during memory
hotplug.

Signed-off-by: Hannes Hering [EMAIL PROTECTED]
---
Jeff, as requested, this patch is now based on davem's net-2.6.git.

diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea.h 
patched_kernel/drivers/net/ehea/ehea.h
--- linux-2.6.27/drivers/net/ehea/ehea.h2008-10-16 11:22:15.0 
+0200
+++ patched_kernel/drivers/net/ehea/ehea.h  2008-10-16 11:23:00.646563117 
+0200
@@ -40,7 +40,7 @@
 #include asm/io.h
 
 #define DRV_NAME   ehea
-#define DRV_VERSIONEHEA_0093
+#define DRV_VERSIONEHEA_0094
 
 /* eHEA capability flags */
 #define DLPAR_PORT_ADD_REM 1
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_main.c 
patched_kernel/drivers/net/ehea/ehea_main.c
--- linux-2.6.27/drivers/net/ehea/ehea_main.c   2008-10-16 11:22:15.0 
+0200
+++ patched_kernel/drivers/net/ehea/ehea_main.c 2008-10-16 11:23:00.646563117 
+0200
@@ -2863,7 +2863,7 @@ static void ehea_rereg_mrs(struct work_s
struct ehea_adapter *adapter;
 
mutex_lock(dlpar_mem_lock);
-   ehea_info(LPAR memory enlarged - re-initializing driver);
+   ehea_info(LPAR memory changed - re-initializing driver);
 
list_for_each_entry(adapter, adapter_list, list)
if (adapter-active_ports) {
@@ -2900,13 +2900,6 @@ static void ehea_rereg_mrs(struct work_s
}
}
 
-   ehea_destroy_busmap();
-   ret = ehea_create_busmap();
-   if (ret) {
-   ehea_error(creating ehea busmap failed);
-   goto out;
-   }
-
clear_bit(__EHEA_STOP_XFER, ehea_driver_flags);
 
list_for_each_entry(adapter, adapter_list, list)
@@ -3519,9 +3512,21 @@ void ehea_crash_handler(void)
 static int ehea_mem_notifier(struct notifier_block *nb,
  unsigned long action, void *data)
 {
+   struct memory_notify *arg = data;
switch (action) {
-   case MEM_OFFLINE:
-   ehea_info(memory has been removed);
+   case MEM_CANCEL_OFFLINE:
+   ehea_info(memory offlining canceled);
+   /* Readd canceled memory block */
+   case MEM_ONLINE:
+   ehea_info(memory is going online);
+   if (ehea_add_sect_bmap(arg-start_pfn, arg-nr_pages))
+   return NOTIFY_BAD;
+   ehea_rereg_mrs(NULL);
+   break;
+   case MEM_GOING_OFFLINE:
+   ehea_info(memory is going offline);
+   if (ehea_rem_sect_bmap(arg-start_pfn, arg-nr_pages))
+   return NOTIFY_BAD;
ehea_rereg_mrs(NULL);
break;
default:
diff -Nurp -X dontdiff linux-2.6.27/drivers/net/ehea/ehea_qmr.c 
patched_kernel/drivers/net/ehea/ehea_qmr.c
--- linux-2.6.27/drivers/net/ehea/ehea_qmr.c2008-10-16 11:22:15.0 
+0200
+++ patched_kernel/drivers/net/ehea/ehea_qmr.c  2008-10-16 11:23:00.646563117 
+0200
@@ -567,7 +567,7 @@ static inline int ehea_calc_index(unsign
 static inline int ehea_init_top_bmap(struct ehea_top_bmap *ehea_top_bmap,
 int dir)
 {
-   if(!ehea_top_bmap-dir[dir]) {
+   if (!ehea_top_bmap-dir[dir]) {
ehea_top_bmap-dir[dir] =
kzalloc(sizeof(struct ehea_dir_bmap), GFP_KERNEL);
if (!ehea_top_bmap-dir[dir])
@@ -578,7 +578,7 @@ static inline int ehea_init_top_bmap(str
 
 static inline int ehea_init_bmap(struct ehea_bmap *ehea_bmap, int top, int dir)
 {
-   if(!ehea_bmap-top[top]) {
+   if (!ehea_bmap-top[top]) {
ehea_bmap-top[top] =
kzalloc(sizeof(struct ehea_top_bmap), GFP_KERNEL);
if (!ehea_bmap-top[top])
@@ -587,53 +587,124 @@ static inline int ehea_init_bmap(struct 
return ehea_init_top_bmap(ehea_bmap-top[top], dir);
 }
 
-static int ehea_create_busmap_callback(unsigned long pfn,
-  unsigned long nr_pages, void *arg)
-{
-   unsigned long i, mr_len, start_section, end_section;
-   start_section = (pfn * PAGE_SIZE) / EHEA_SECTSIZE;
-   end_section = start_section + ((nr_pages * PAGE_SIZE) / EHEA_SECTSIZE);
-   mr_len = *(unsigned long *)arg;
+static DEFINE_MUTEX(ehea_busmap_mutex);
+static unsigned long ehea_mr_len;
 
-   if (!ehea_bmap)
-   ehea_bmap = kzalloc(sizeof(struct ehea_bmap), GFP_KERNEL);
-   if (!ehea_bmap)
-   return -ENOMEM;
+#define EHEA_BUSMAP_ADD_SECT 1
+#define EHEA_BUSMAP_REM_SECT 0
 
-   for (i = start_section; i  end_section; i++) {
-   int ret;
-   int top, dir, idx;
-   u64 vaddr;
+static void ehea_rebuild_busmap(void)
+{
+   u64 vaddr = EHEA_BUSMAP_START;
+   int top, dir, idx;
+
+   for (top 

RE: Problems with PCI-E devices not being detected with switch

[Ayman El-Khashab]

Benjamin Herrenschmidt wrote:
 On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
 
 Note for people on CC: This is a problem on 460EX on a canyonland
 using the 4x port. 
 
 The problem occurs when Linux boots. It sees the switch (and looking
 in /sys/bus/... confirms it), but nothing on the downstream sides of
 the switch (secondary busses) is visible.  There were no boot
 messages to indicate it had seen the Sil 3531 and it doesn't
 function.  We've also tried other PCI-E devices (NI GPIB) on the
 downstream side and they are also not detected, so it seems to be
 something in Linux, my configuration, etc.  I've included the boot
 messages below from u-boot and the kernel.  It is more than just the
 pci boot messages, but I was not sure if something else in the log
 with provide some insight. 
 
 The messages below look really fishy indeed:
 
 pci 0001:02:00.0: unknown header type 03, ignoring device pci
 0001:02:01.0: unknown header type 41, ignoring device pci
 0001:02:02.0: unknown header type 03, ignoring device pci
 0001:02:03.0: unknown header type 41, ignoring device pci
 0001:02:04.0: ignoring class 1d09 (doesn't match header type 02) pci
 0001:02:05.0: unknown header type 41, ignoring device pci
 0001:02:06.0: ignoring class 1d09 (doesn't match header type 02) pci
 0001:02:07.0: unknown header type 41, ignoring device pci
 0001:02:08.0: unknown header type 03, ignoring device pci
 0001:02:09.0: unknown header type 41, ignoring device pci
 0001:02:0a.0: ignoring class 7d09 (doesn't match header type 02) pci
 0001:02:0b.0: unknown header type 41, ignoring device pci
 0001:02:0c.0: ignoring class 1d01 (doesn't match header type 02) pci
 0001:02:0d.0: unknown header type 41, ignoring device pci
 0001:02:0e.0: ignoring class 7d09 (doesn't match header type 02) pci
 0001:02:0f.0: unknown header type 41, ignoring device pci
 0001:02:10.0: unknown header type 03, ignoring device pci
 0001:02:11.0: unknown header type 41, ignoring device pci
 0001:02:12.0: unknown header type 03, ignoring device pci
 0001:02:13.0: unknown header type 41, ignoring device pci
 0001:02:14.0: unknown header type 03, ignoring device pci
 0001:02:15.0: unknown header type 41, ignoring device pci
 0001:02:16.0: ignoring class 3d09 (doesn't match header type 02) pci
 0001:02:17.0: unknown header type 41, ignoring device pci
 0001:02:18.0: unknown header type 03, ignoring device pci
 0001:02:19.0: unknown header type 41, ignoring device pci
 0001:02:1a.0: unknown header type 03, ignoring device pci
 0001:02:1b.0: unknown header type 41, ignoring device pci
 0001:02:1c.0: ignoring class 5d01 (doesn't match header type 02) pci
 0001:02:1d.0: unknown header type 41, ignoring device pci
 0001:02:1e.0: unknown header type 03, ignoring device pci
 0001:02:1f.0: unknown header type 41, ignoring device
 
 
 Ayman, can you try adding a long delay (such as msleep(5000), ie 5s)
 at the beginning of pcibios_init() in arch/powerpc/kernel/pci_32.c ? 
 This will add 5s delay between the init/reset of the port and the
 probing by linux. Do that help ? 
 

Thanks for your help.  I did try a 5s delay and other than the boot
taking an extra couple of seconds, there was no change.  The messages
above unknown header still showed up.  Downstream devices were not
found.
BTW, this is with both the Denx kernel tree and the official 2.6.27
kernel.  
Both have the same results. One added note, just to rule out bad
electronics,
I have confirmed that the switch+sata work correctly together if placed
into a plain x86 pc with 2.6.24.  So the electronics are fine.

Ayman
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Johannes Berg]

On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
 
 
  net/sched/sch_generic.c: In function 'dev_watchdog':
  net/sched/sch_generic.c:224: warning: unused variable 'drivername'
 
 Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
 on the stack looks unused.

I've complained about this to Arjan before, we actually lose all
messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
for warnings too.

johannes


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Mark Brown]

On Wed, Oct 15, 2008 at 09:33:37PM -0700, Andrew Morton wrote:

 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)
 sound/soc/soc-dapm.c:1029: warning: 'snd_soc_dapm_connect_input' is 
 deprecated (declared at sound/soc/soc-dapm.c:1026)

I should submit the patch to remove this now that 2.6.27 is out - the
warnings are generated by EXPORT_SYMBOL_GPL() - I couldn't see a way to
mark the function as deprecated without removing the export.

 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_write':
 sound/soc/codecs/tlv320aic23.c:104: warning: passing argument 2 of 
 'codec-hw_write' makes pointer from integer without a cast
 sound/soc/codecs/tlv320aic23.c: In function 'tlv320aic23_set_dai_sysclk':
 sound/soc/codecs/tlv320aic23.c:424: warning: unused variable 'codec'

The author already provided a patch to fix these.  Takashi has sent a
pull request to Linus including that already, IIRC.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Fix linking modules against crtsavres.o

[Grant Likely]

On Thu, Oct 09, 2008 at 09:51:25PM +0200, Bernhard Reutner-Fischer wrote:
 Hi,
 
 [ http://bugzilla.kernel.org/show_bug.cgi?id=11143 has it all]
 
 targeting ppc(32), e.g. 405 (!fp), previously i got:
   CC  drivers/char/hw_random/rng-core.mod.o
   LD [M]  drivers/char/hw_random/rng-core.ko
 /there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-uclibc-ld:
 arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
 
   * Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold prerequisite
   files for modules.
   * arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
   * scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
   (cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
   Provide rule to build objects from assembler.
 
 The attached patch (same as attached to abovementioned bug) fixes this.
 I'm asking the ppc maintainers or you, Sam, to consider something to
 that effect for inclusing in the stable series.
 thanks,

This patch solves the problem for me.  Without it building modules
before the kernel proper fails to find crtsavres.o when linking.

Ben, Paul or Sam, could you please look at this and make comment
if it is the right approach?

I also agree that this should be back ported to the stable series

(Note: for some reason this patch did *not* show up in patchwork).

Cheers,
g.

 Fix linking modules against crtsavres.o
 
 Previously we got
   CC  drivers/char/hw_random/rng-core.mod.o
   LD [M]  drivers/char/hw_random/rng-core.ko
 /there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/bin/powerpc-linux-uclibc-ld:
  arch/powerpc/lib/crtsavres.o: No such file: No such file or directory
 
   * Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold prerequisite
   files for modules.
   * arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
   * scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
   (cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
   Provide rule to build objects from assembler.
 
 Signed-off-by:  Bernhard Reutner-Fischer  [EMAIL PROTECTED]
 
 diff -rup ../../x/linux-2.6.26.5.old/arch/powerpc/Makefile 
 linux-2.6.26.5/arch/powerpc/Makefile
 --- ../../x/linux-2.6.26.5.old/arch/powerpc/Makefile  2008-09-08 
 19:40:20.0 +0200
 +++ linux-2.6.26.5/arch/powerpc/Makefile  2008-10-07 14:28:08.0 
 +0200
 @@ -97,7 +97,7 @@ else
   KBUILD_CFLAGS += $(call cc-option,-mtune=power4)
  endif
  else
 -LDFLAGS_MODULE   += arch/powerpc/lib/crtsavres.o
 +LDFLAGS_MODULE_PREREQ += arch/powerpc/lib/crtsavres.o
  endif
  
  ifeq ($(CONFIG_TUNE_CELL),y)
 diff -rup ../../x/linux-2.6.26.5.old/Makefile linux-2.6.26.5/Makefile
 --- ../../x/linux-2.6.26.5.old/Makefile   2008-09-08 19:40:20.0 
 +0200
 +++ linux-2.6.26.5/Makefile   2008-10-07 14:15:59.0 +0200
 @@ -318,6 +318,7 @@ MODFLAGS  = -DMODULE
  CFLAGS_MODULE   = $(MODFLAGS)
  AFLAGS_MODULE   = $(MODFLAGS)
  LDFLAGS_MODULE  =
 +LDFLAGS_MODULE_PREREQ  =
  CFLAGS_KERNEL=
  AFLAGS_KERNEL=
  
 @@ -342,7 +343,7 @@ KERNELVERSION = $(VERSION).$(PATCHLEVEL)
  export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
  export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
  export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
 -export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
 +export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE LDFLAGS_MODULE_PREREQ CHECK 
 CHECKFLAGS
  
  export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
  export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
 diff -rup ../../x/linux-2.6.26.5.old/scripts/Makefile.modpost 
 linux-2.6.26.5/scripts/Makefile.modpost
 --- ../../x/linux-2.6.26.5.old/scripts/Makefile.modpost   2008-09-08 
 19:40:20.0 +0200
 +++ linux-2.6.26.5/scripts/Makefile.modpost   2008-10-07 14:24:34.0 
 +0200
 @@ -122,14 +122,21 @@ quiet_cmd_cc_o_c = CC  $@
cmd_cc_o_c = $(CC) $(c_flags) $(CFLAGS_MODULE) \
  -c -o $@ $
  
 -$(modules:.ko=.mod.o): %.mod.o: %.mod.c FORCE
 +quiet_cmd_as_o_S = AS $(quiet_modtag)  $@
 +cmd_as_o_S   = $(CC) $(a_flags) $(AFLAGS_MODULE) -c -o $@ $
 +
 +$(LDFLAGS_MODULE_PREREQ): %.o: %.S FORCE
 + $(call if_changed_dep,as_o_S)
 +
 +$(modules:.ko=.mod.o): %.mod.o: %.mod.c $(LDFLAGS_MODULE_PREREQ) FORCE
   $(call if_changed_dep,cc_o_c)
  
  targets += $(modules:.ko=.mod.o)
  
  # Step 6), final link of the modules
  quiet_cmd_ld_ko_o = LD [M]  $@
 -  cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(LDFLAGS_MODULE) -o $@  
 \
 +  cmd_ld_ko_o = $(LD) -r $(LDFLAGS) $(LDFLAGS_MODULE_PREREQ) \
 +   $(LDFLAGS_MODULE) -o $@   \
 $(filter-out FORCE,$^)
  
  $(modules): %.ko :%.o %.mod.o FORCE

 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@ozlabs.org
 

Re: [PATCH] Fix linking modules against crtsavres.o

[Kumar Gala]

On Oct 16, 2008, at 10:24 AM, Grant Likely wrote:

On Thu, Oct 09, 2008 at 09:51:25PM +0200, Bernhard Reutner-Fischer  
wrote:

Hi,

[ http://bugzilla.kernel.org/show_bug.cgi?id=11143 has it all]

targeting ppc(32), e.g. 405 (!fp), previously i got:
 CC  drivers/char/hw_random/rng-core.mod.o
 LD [M]  drivers/char/hw_random/rng-core.ko
/there/src/buildroot.git.ppc/build_powerpc_nofpu/staging_dir/usr/ 
bin/powerpc-linux-uclibc-ld:

arch/powerpc/lib/crtsavres.o: No such file: No such file or directory

	* Makefile (LDFLAGS_MODULE_PREREQ): New variable to hold  
prerequisite

files for modules.
* arch/powerpc/Makefile: add crtsavres.o to LDFLAGS_MODULE_PREREQ.
* scripts/Makefile.modpost (cmd_as_o_S): Copy from Makefile.build.
(cmd_ld_ko_o): Also link LDFLAGS_MODULE_PREREQ.
Provide rule to build objects from assembler.

The attached patch (same as attached to abovementioned bug) fixes  
this.

I'm asking the ppc maintainers or you, Sam, to consider something to
that effect for inclusing in the stable series.
thanks,


This patch solves the problem for me.  Without it building modules
before the kernel proper fails to find crtsavres.o when linking.

Ben, Paul or Sam, could you please look at this and make comment
if it is the right approach?

I also agree that this should be back ported to the stable series

(Note: for some reason this patch did *not* show up in patchwork).


because it was sent as an attachment.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] i2c-cpm: Suppress autoprobing for devices

[Kumar Gala]

On Oct 16, 2008, at 6:13 AM, Wolfram Sang wrote:



Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also  
remove
automatic probing for this i2c controller. Might need updates to dts  
files

using it.

Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
---
drivers/i2c/busses/i2c-cpm.c |1 -
1 file changed, 1 deletion(-)


The i2c list should be CC'd.  Jean should pick this up.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: linux-next: build failure

[Jeremy Fitzhardinge]

Ingo Molnar wrote:

* Stephen Rothwell [EMAIL PROTECTED] wrote:

  

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

In file included from arch/powerpc/include/asm/mmu-hash64.h:17,
 from arch/powerpc/include/asm/mmu.h:8,
 from arch/powerpc/include/asm/pgtable.h:8,
 from arch/powerpc/mm/slb.c:20:
arch/powerpc/include/asm/page.h:76: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'memstart_addr'
arch/powerpc/include/asm/page.h:77: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'kernstart_addr'

Caused by commit 600715dcdf567c86f8b2c6173fcfb4b873e25a19 (generic: add
phys_addr_t for holding physical addresses) from the tip-core tree.
This only fails if CONFIG_RELOCATABLE is set.

I have applied the patch below.



applied to tip/core/urgent, thanks Stephen!
  


Shouldn't this go via a ppc tree?  Won't having ppc changes in tip.git 
make people grumpy?


   J
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 0/7 RFC] Handle I2C GPIO controllers with the OF (was: pca9539 I2C gpio expander)

[Anton Vorontsov]

Hi all,

Recently there was a question about I2C GPIO controllers and how should
we handle them with the OpenFirmware and such.

Here is the attempt to connect I2C GPIO controllers to the
OpenFirmware device tree, without writing an OF-specific bindings
for each driver.

The salt is in these two patches:

[PATCH 3/7] of: fill the archdata for I2C devices
^ Here we're storing the device tree node into the I2C device.

[PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add,remove} calls
^ And here we extracting the the stored node to put the registered
  of_gpio_chip into that node.


How does it look?

p.s. The original question:

- Forwarded message from Steven A. Falco [EMAIL PROTECTED] -

Date: Tue, 14 Oct 2008 14:10:25 -0400
From: Steven A. Falco [EMAIL PROTECTED]
To: linuxppc-dev@ozlabs.org linuxppc-dev@ozlabs.org
Subject: pca9539 I2C gpio expander
List-Id: Linux on PowerPC Developers Mail List linuxppc-dev.ozlabs.org

I am attempting to use a pca9539 I2C gpio driver on a PPC440EPx board.  The
driver is drivers/gpio/pca953x.c.  I've added an entry to the .dts file:

IIC0: [EMAIL PROTECTED] {
compatible = ibm,iic-440epx, ibm,iic;
...
[EMAIL PROTECTED] {
compatible = ti,pca9539;
reg = 76;
};
};

of_register_i2c_devices sees this entry and calls i2c_new_device.
i2c_new_device copies info-platform_data to client-dev.platform_data, but
I think that this structure is empty (at least I don't see where
of_register_i2c_devices would set it).

pca953x_probe is eventually called, but it expects to find its lowest gpio
number in client-dev.platform_data-gpio_base, which has not been set.  So
pca953x_probe returns -ENODEV.

I don't understand where the disconnect is.  Should I be able to use the
pca953x.c driver, or is it somehow incompatible?

If it is incompatible, is there a strategy for making it compatible?

Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

- End forwarded message -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 2/7] i2c: add info-archdata field

[Anton Vorontsov]

If present the info-archdata is copied into the dev-archdata.
Some (OpenFirmware) platforms need it.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 drivers/i2c/i2c-core.c |3 +++
 include/linux/i2c.h|2 ++
 2 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 42e852d..5a485c2 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -266,6 +266,9 @@ i2c_new_device(struct i2c_adapter *adap, struct 
i2c_board_info const *info)
 
client-dev.platform_data = info-platform_data;
 
+   if (info-archdata)
+   client-dev.archdata = *info-archdata;
+
client-flags = info-flags;
client-addr = info-addr;
client-irq = info-irq;
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 0611512..3e358d3 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -240,6 +240,7 @@ static inline void i2c_set_clientdata (struct i2c_client 
*dev, void *data)
  * @flags: to initialize i2c_client.flags
  * @addr: stored in i2c_client.addr
  * @platform_data: stored in i2c_client.dev.platform_data
+ * @archdata: copied into i2c_client.dev.archdata
  * @irq: stored in i2c_client.irq
  *
  * I2C doesn't actually support hardware probing, although controllers and
@@ -259,6 +260,7 @@ struct i2c_board_info {
unsigned short  flags;
unsigned short  addr;
void*platform_data;
+   struct dev_archdata *archdata;
int irq;
 };
 
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 1/7] powerpc and sparc: introduce dev_archdata node accessors

[Anton Vorontsov]

The name of the device_node field differ across the platforms, so we
have to implement inlined accessors. This is needed to avoid ugly
#ifdef in the generic code.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/include/asm/device.h |   12 
 arch/sparc/include/asm/device.h   |   12 
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/device.h 
b/arch/powerpc/include/asm/device.h
index dfd504c..7d2277c 100644
--- a/arch/powerpc/include/asm/device.h
+++ b/arch/powerpc/include/asm/device.h
@@ -18,4 +18,16 @@ struct dev_archdata {
void*dma_data;
 };
 
+static inline void dev_archdata_set_node(struct dev_archdata *ad,
+struct device_node *np)
+{
+   ad-of_node = np;
+}
+
+static inline struct device_node *
+dev_archdata_get_node(const struct dev_archdata *ad)
+{
+   return ad-of_node;
+}
+
 #endif /* _ASM_POWERPC_DEVICE_H */
diff --git a/arch/sparc/include/asm/device.h b/arch/sparc/include/asm/device.h
index 19790eb..3702e08 100644
--- a/arch/sparc/include/asm/device.h
+++ b/arch/sparc/include/asm/device.h
@@ -20,4 +20,16 @@ struct dev_archdata {
int numa_node;
 };
 
+static inline void dev_archdata_set_node(struct dev_archdata *ad,
+struct device_node *np)
+{
+   ad-prom_node = np;
+}
+
+static inline struct device_node *
+dev_archdata_get_node(const struct dev_archdata *ad)
+{
+   return ad-prom_node;
+}
+
 #endif /* _ASM_SPARC_DEVICE_H */
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 3/7] of: fill the archdata for I2C devices

[Anton Vorontsov]

For I2C devices we just setting the the node pointer in the archdata.
This is needed so that the other code would know device's node.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 drivers/of/of_i2c.c |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..f9e18ed 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -24,6 +24,7 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
 
for_each_child_of_node(adap_node, node) {
struct i2c_board_info info = {};
+   struct dev_archdata dev_ad = {};
const u32 *addr;
int len;
 
@@ -41,6 +42,9 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
 
info.addr = *addr;
 
+   dev_archdata_set_node(dev_ad, node);
+   info.archdata = dev_ad;
+
request_module(info.type);
 
result = i2c_new_device(adap, info);
@@ -51,6 +55,13 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
irq_dispose_mapping(info.irq);
continue;
}
+
+   /*
+* Get the node to not lose the dev_archdata-of_node.
+* Currently there is no way to put it back, as well as no
+* of_unregister_i2c_devices() call.
+*/
+   of_node_get(node);
}
 }
 EXPORT_SYMBOL(of_register_i2c_devices);
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls

[Anton Vorontsov]

Any GPIO controller that have a device associated with it is encouraged to
register/unregister the gpiochips with dev_gpiochip_*() calls.

Platform may redefine these calls to glue the gpiochips with the
architecture-specific code.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 include/asm-generic/gpio.h |   44 
 1 files changed, 44 insertions(+), 0 deletions(-)

diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 0f99ad3..f31c7ae 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -89,6 +89,50 @@ extern int __must_check gpiochip_reserve(int start, int 
ngpio);
 extern int gpiochip_add(struct gpio_chip *chip);
 extern int __must_check gpiochip_remove(struct gpio_chip *chip);
 
+/*
+ * Platforms can define their own __dev_ versions to glue gpio_chips with the
+ * architecture-specific code.
+ */
+#ifndef __dev_gpiochip_add
+#define __dev_gpiochip_add __dev_gpiochip_add
+static inline int __dev_gpiochip_add(struct device *dev,
+struct gpio_chip *chip)
+{
+   chip-dev = dev;
+   return gpiochip_add(chip);
+}
+#endif /* __dev_gpiochip_add */
+
+#ifndef __dev_gpiochip_remove
+#define __dev_gpiochip_remove __dev_gpiochip_remove
+static inline int __dev_gpiochip_remove(struct device *dev,
+   struct gpio_chip *chip)
+{
+   return gpiochip_remove(chip);
+}
+#endif /* __dev_gpiochip_remove */
+
+/**
+ * dev_gpiochip_add - register a gpio_chip for a device
+ * @dev: device to register gpio_chip for
+ * @chip: the chip to register
+ * Context: potentially before irqs or kmalloc will work
+ *
+ * This function takes the extra @dev argument that is used to associate
+ * the chip with a device. Otherwise it behaves the same way as the
+ * gpiochip_add().
+ */
+#define dev_gpiochip_add(dev, chip) __dev_gpiochip_add((dev), (chip))
+
+/**
+ * dev_gpiochip_remove - unregister a gpio_chip
+ * @dev: device to remove the chip from
+ * @chip: the chip to unregister
+ *
+ * Use this function to unregister the chip that was registered using
+ * dev_gpiochip_add().
+ */
+#define dev_gpiochip_remove(dev, chip) __dev_gpiochip_remove((dev), (chip))
 
 /* Always use the library code for GPIO management calls,
  * or when sleeping may be involved.
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add,remove} calls

[Anton Vorontsov]

And let the gpiolib forward all dev_gpiochip_ calls to of_ versions, there
we can glue the gpiochips with the device tree.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 arch/powerpc/include/asm/gpio.h |7 +++-
 drivers/of/gpio.c   |   75 +-
 include/linux/of_gpio.h |7 
 3 files changed, 86 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/gpio.h b/arch/powerpc/include/asm/gpio.h
index ea04632..92610b1 100644
--- a/arch/powerpc/include/asm/gpio.h
+++ b/arch/powerpc/include/asm/gpio.h
@@ -14,8 +14,13 @@
 #ifndef __ASM_POWERPC_GPIO_H
 #define __ASM_POWERPC_GPIO_H
 
-#include linux/errno.h
+/* Tell the gpiolib that we'll handle the dev_gpiochip_* calls. */
+#define __dev_gpiochip_add of_dev_gpiochip_add
+#define __dev_gpiochip_remove of_dev_gpiochip_remove
+
 #include asm-generic/gpio.h
+#include linux/errno.h
+#include linux/of_gpio.h
 
 #ifdef CONFIG_GPIOLIB
 
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 7cd7301..b6f56af 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -12,12 +12,33 @@
  */
 
 #include linux/kernel.h
+#include linux/device.h
 #include linux/errno.h
 #include linux/io.h
 #include linux/of.h
 #include linux/of_gpio.h
 #include asm/prom.h
 
+static struct gpio_chip *of_gc_to_gc(struct of_gpio_chip *of_gc)
+{
+   /*
+* Currently there are two ways to register OF GPIO controllers:
+*
+* 1. Allocating the of_gpio_chip structure and passing the
+*of_gc-gc pointer to the gpiochip_add. (Can use container_of
+*to convert the gpio_chip to the of_gpio_chip.)
+*
+* 2. Allocating and registering the gpio_chip structure separately
+*from the of_gpio_chip. (Since two allocations are separate,
+*container_of won't work.)
+*
+* As time goes by we may kill the first option.
+*/
+   if (of_gc-chip)
+   return of_gc-chip;
+   return of_gc-gc;
+}
+
 /**
  * of_get_gpio - Get a GPIO number from the device tree to use with GPIO API
  * @np:device node to get GPIO from
@@ -63,7 +84,7 @@ int of_get_gpio(struct device_node *np, int index)
if (ret  0)
goto err1;
 
-   ret += of_gc-gc.base;
+   ret += of_gc_to_gc(of_gc)-base;
 err1:
of_node_put(gc);
 err0:
@@ -87,7 +108,7 @@ int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct 
device_node *np,
 {
const u32 *gpio = gpio_spec;
 
-   if (*gpio  of_gc-gc.ngpio)
+   if (*gpio  of_gc_to_gc(of_gc)-ngpio)
return -EINVAL;
 
return *gpio;
@@ -161,3 +182,53 @@ err0:
return ret;
 }
 EXPORT_SYMBOL(of_mm_gpiochip_add);
+
+int of_dev_gpiochip_add(struct device *dev, struct gpio_chip *chip)
+{
+   struct device_node *np = dev_archdata_get_node(dev-archdata);
+   struct of_gpio_chip *of_gc;
+   int ret;
+
+   if (!np || np-data)
+   return -EINVAL;
+
+   of_gc = kzalloc(sizeof(*of_gc), GFP_KERNEL);
+   if (!of_gc)
+   return -ENOMEM;
+   /*
+* NOTE: for simple cases we use the simple_xlate with 2 cells scheme.
+* You can always overwrite it with an exceptions list that would
+* match on of_device_is_compatible().
+*/
+   of_gc-gpio_cells = 2;
+   of_gc-xlate = of_gpio_simple_xlate;
+
+   chip-dev = dev;
+   of_gc-chip = chip;
+   np-data = of_gc;
+
+   ret = gpiochip_add(chip);
+   if (ret)
+   goto err_gpiochip_add;
+   return 0;
+
+err_gpiochip_add:
+   np-data = NULL;
+   chip-dev = NULL;
+   kfree(of_gc);
+   return ret;
+}
+EXPORT_SYMBOL(of_dev_gpiochip_add);
+
+int of_dev_gpiochip_remove(struct device *dev, struct gpio_chip *chip)
+{
+   struct device_node *np = dev_archdata_get_node(dev-archdata);
+   int ret;
+
+   ret = gpiochip_remove(chip);
+   if (ret)
+   return ret;
+   np-data = NULL;
+   return 0;
+}
+EXPORT_SYMBOL(of_dev_gpiochip_remove);
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 67db101..273cd79 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -14,16 +14,21 @@
 #ifndef __LINUX_OF_GPIO_H
 #define __LINUX_OF_GPIO_H
 
+#include linux/compiler.h
 #include linux/errno.h
 #include linux/gpio.h
 
 #ifdef CONFIG_OF_GPIO
 
+struct device_node;
+struct device;
+
 /*
  * Generic OF GPIO chip
  */
 struct of_gpio_chip {
struct gpio_chip gc;
+   struct gpio_chip *chip;
int gpio_cells;
int (*xlate)(struct of_gpio_chip *of_gc, struct device_node *np,
 const void *gpio_spec);
@@ -53,6 +58,8 @@ static inline struct of_mm_gpio_chip 
*to_of_mm_gpio_chip(struct gpio_chip *gc)
 extern int of_get_gpio(struct device_node *np, int index);
 extern int of_mm_gpiochip_add(struct device_node *np,
  struct of_mm_gpio_chip *mm_gc);
+extern 

[PATCH 6/7] gpio/pca953x: convert to dev_gpiochip_add and make it work with the OF

[Anton Vorontsov]

With OpenFirmware we can't handle platform data for the devices, so let's
not strictly depend on it. That way we can't set polarity invertion for
this controller, but we'll handle this with active-low/high GPIO flags in
the OF tree.

Also switch the driver to dev_gpiochip calls, so that OF subsystem would
know about the newly registered chips.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 drivers/gpio/pca953x.c |   24 +---
 1 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c
index cc84686..6e51fda 100644
--- a/drivers/gpio/pca953x.c
+++ b/drivers/gpio/pca953x.c
@@ -188,7 +188,6 @@ static void pca953x_setup_gpio(struct pca953x_chip *chip, 
int gpios)
gc-base = chip-gpio_start;
gc-ngpio = gpios;
gc-label = chip-client-name;
-   gc-dev = chip-client-dev;
gc-owner = THIS_MODULE;
 }
 
@@ -200,8 +199,6 @@ static int __devinit pca953x_probe(struct i2c_client 
*client,
int ret;
 
pdata = client-dev.platform_data;
-   if (pdata == NULL)
-   return -ENODEV;
 
chip = kzalloc(sizeof(struct pca953x_chip), GFP_KERNEL);
if (chip == NULL)
@@ -209,7 +206,10 @@ static int __devinit pca953x_probe(struct i2c_client 
*client,
 
chip-client = client;
 
-   chip-gpio_start = pdata-gpio_base;
+   if (pdata)
+   chip-gpio_start = pdata-gpio_base;
+   else
+   chip-gpio_start = -1;
 
/* initialize cached registers from their original values.
 * we can't share this chip with another i2c master.
@@ -225,16 +225,18 @@ static int __devinit pca953x_probe(struct i2c_client 
*client,
goto out_failed;
 
/* set platform specific polarity inversion */
-   ret = pca953x_write_reg(chip, PCA953X_INVERT, pdata-invert);
-   if (ret)
-   goto out_failed;
+   if (pdata) {
+   ret = pca953x_write_reg(chip, PCA953X_INVERT, pdata-invert);
+   if (ret)
+   goto out_failed;
+   }
 
 
-   ret = gpiochip_add(chip-gpio_chip);
+   ret = dev_gpiochip_add(client-dev, chip-gpio_chip);
if (ret)
goto out_failed;
 
-   if (pdata-setup) {
+   if (pdata  pdata-setup) {
ret = pdata-setup(client, chip-gpio_chip.base,
chip-gpio_chip.ngpio, pdata-context);
if (ret  0)
@@ -255,7 +257,7 @@ static int pca953x_remove(struct i2c_client *client)
struct pca953x_chip *chip = i2c_get_clientdata(client);
int ret = 0;
 
-   if (pdata-teardown) {
+   if (pdata  pdata-teardown) {
ret = pdata-teardown(client, chip-gpio_chip.base,
chip-gpio_chip.ngpio, pdata-context);
if (ret  0) {
@@ -265,7 +267,7 @@ static int pca953x_remove(struct i2c_client *client)
}
}
 
-   ret = gpiochip_remove(chip-gpio_chip);
+   ret = dev_gpiochip_remove(client-dev, chip-gpio_chip);
if (ret) {
dev_err(client-dev, %s failed, %d\n,
gpiochip_remove(), ret);
-- 
1.5.6.3

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH 7/7] i2c/mcu_mpc8349emitx: convert to the new I2C/OF/GPIO infrastructure

[Anton Vorontsov]

With the new subsystem it's much easier to handle I2C GPIO controllers.
Now drivers don't need to deal with the OF-specific bits.

Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
---
 drivers/i2c/chips/mcu_mpc8349emitx.c |   65 ++---
 1 files changed, 12 insertions(+), 53 deletions(-)

diff --git a/drivers/i2c/chips/mcu_mpc8349emitx.c 
b/drivers/i2c/chips/mcu_mpc8349emitx.c
index 82a9bcb..985a1a4 100644
--- a/drivers/i2c/chips/mcu_mpc8349emitx.c
+++ b/drivers/i2c/chips/mcu_mpc8349emitx.c
@@ -18,8 +18,6 @@
 #include linux/mutex.h
 #include linux/i2c.h
 #include linux/gpio.h
-#include linux/of.h
-#include linux/of_gpio.h
 #include asm/prom.h
 #include asm/machdep.h
 
@@ -36,7 +34,7 @@ struct mcu {
struct mutex lock;
struct device_node *np;
struct i2c_client *client;
-   struct of_gpio_chip of_gc;
+   struct gpio_chip gc;
u8 reg_ctrl;
 };
 
@@ -55,8 +53,7 @@ static void mcu_power_off(void)
 
 static void mcu_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
 {
-   struct of_gpio_chip *of_gc = to_of_gpio_chip(gc);
-   struct mcu *mcu = container_of(of_gc, struct mcu, of_gc);
+   struct mcu *mcu = container_of(gc, struct mcu, gc);
u8 bit = 1  (4 + gpio);
 
mutex_lock(mcu-lock);
@@ -75,52 +72,6 @@ static int mcu_gpio_dir_out(struct gpio_chip *gc, unsigned 
int gpio, int val)
return 0;
 }
 
-static int mcu_gpiochip_add(struct mcu *mcu)
-{
-   struct device_node *np;
-   struct of_gpio_chip *of_gc = mcu-of_gc;
-   struct gpio_chip *gc = of_gc-gc;
-   int ret;
-
-   np = of_find_compatible_node(NULL, NULL, fsl,mcu-mpc8349emitx);
-   if (!np)
-   return -ENODEV;
-
-   gc-owner = THIS_MODULE;
-   gc-label = np-full_name;
-   gc-can_sleep = 1;
-   gc-ngpio = MCU_NUM_GPIO;
-   gc-base = -1;
-   gc-set = mcu_gpio_set;
-   gc-direction_output = mcu_gpio_dir_out;
-   of_gc-gpio_cells = 2;
-   of_gc-xlate = of_gpio_simple_xlate;
-
-   np-data = of_gc;
-   mcu-np = np;
-
-   /*
-* We don't want to lose the node, its -data and -full_name...
-* So, if succeeded, we don't put the node here.
-*/
-   ret = gpiochip_add(gc);
-   if (ret)
-   of_node_put(np);
-   return ret;
-}
-
-static int mcu_gpiochip_remove(struct mcu *mcu)
-{
-   int ret;
-
-   ret = gpiochip_remove(mcu-of_gc.gc);
-   if (ret)
-   return ret;
-   of_node_put(mcu-np);
-
-   return 0;
-}
-
 static int __devinit mcu_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
 {
@@ -140,7 +91,15 @@ static int __devinit mcu_probe(struct i2c_client *client,
goto err;
mcu-reg_ctrl = ret;
 
-   ret = mcu_gpiochip_add(mcu);
+   mcu-gc.owner = THIS_MODULE;
+   mcu-gc.label = client-dev.bus_id;
+   mcu-gc.can_sleep = 1;
+   mcu-gc.ngpio = MCU_NUM_GPIO;
+   mcu-gc.base = -1;
+   mcu-gc.set = mcu_gpio_set;
+   mcu-gc.direction_output = mcu_gpio_dir_out;
+
+   ret = dev_gpiochip_add(client-dev, mcu-gc);
if (ret)
goto err;
 
@@ -167,7 +126,7 @@ static int __devexit mcu_remove(struct i2c_client *client)
glob_mcu = NULL;
}
 
-   ret = mcu_gpiochip_remove(mcu);
+   ret = dev_gpiochip_remove(client-dev, mcu-gc);
if (ret)
return ret;
i2c_set_clientdata(client, NULL);
-- 
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Steven Rostedt]

On Thu, 16 Oct 2008, Josh Boyer wrote:

 On Sat, Sep 06, 2008 at 02:03:47PM +0200, Ingo Molnar wrote:
 
 * Steven Rostedt [EMAIL PROTECTED] wrote:
 
  I spent the day chasing a bug that would hang PPC on boot up when 
  ftrace is configured in. I found that it was simply a stupid bug I did 
  to handle the non MCOUNT_RECORD case. Since I was testing only on x86, 
  and the MCOUNT_RECORD is automatically set for dynamic ftrace if it is 
  available, I did not test the case where MCOUNT_RECORD was not set.
  
  I have not finished porting MCOUNT_RECORD to PPC, but have found that 
  it has caused some issues for archs that do not support it yet.
  
  This patch series handles these cases.
 
 applied to tip/tracing/ftrace, thanks Steve.
 
 Are these two merged yet?  I just spent the better part of the morning
 trying to figure out why various Fedora kernels based on 2.6.27-rcX and
 2.6.27 final hung on my G5 and finally got one booting with FTRACE
 disabled.

My powerbook does not boot with ftrace enabled. I'm currently debugging 
it. When I get it working, you'll see patches.

They will be to linux-tip though, and not for the current mainline (unless 
the code in linux-tip gets merged).

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Steven Rostedt]

On Thu, 16 Oct 2008, Josh Boyer wrote:
 
 My powerbook does not boot with ftrace enabled. I'm currently debugging 
 it. When I get it working, you'll see patches.
 
 Well, that's why I asked.  You sent 2 patches out over a month ago that
 don't appear to have shown up in any Linus or PowerPC tree.

OK, I'll see if those patches fixes my problem.

 
 They will be to linux-tip though, and not for the current mainline (unless 
 the code in linux-tip gets merged).
 
 If linux-tip is some x86 topic branch, I think that's the wrong place for
 fixes that are needed on non-x86 arches.

linux-tip has been used by more that x86 specific changes. It's where we 
have been developing ftrace itself.

My original port to PPC first landed into linux-tip.

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Steven Rostedt]

On Thu, 16 Oct 2008, Josh Boyer wrote:
 
 Well, that's why I asked.  You sent 2 patches out over a month ago that
 don't appear to have shown up in any Linus or PowerPC tree.

Oh, the patches I sent on here, are not to solve this issue. It was 
actually solving issues in linux-tip itself.

I'm still looking into the cause for ftrace not to boot on PPC.

-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Josh Boyer]

On Thu, 16 Oct 2008 14:45:15 -0400 (EDT)
Steven Rostedt [EMAIL PROTECTED] wrote:

 
 On Thu, 16 Oct 2008, Josh Boyer wrote:
  
  Well, that's why I asked.  You sent 2 patches out over a month ago that
  don't appear to have shown up in any Linus or PowerPC tree.
 
 Oh, the patches I sent on here, are not to solve this issue. It was 
 actually solving issues in linux-tip itself.

Totally confused as to what linux-tip is, but ok.

 I'm still looking into the cause for ftrace not to boot on PPC.

There were issues with -pg and some other compile flag on PPC at one
point.  I think you worked that out with Ben, but I don't recall.

Anyway, if you want a tester let me know.  It seems 2.6.27.1 should be
fine since FTRACE was disabled, but for .28-rc1 it would be cool if it
worked :).

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Josh Boyer]

On Thu, Oct 16, 2008 at 02:22:48PM -0400, Steven Rostedt wrote:

On Thu, 16 Oct 2008, Josh Boyer wrote:

 On Sat, Sep 06, 2008 at 02:03:47PM +0200, Ingo Molnar wrote:
 
 * Steven Rostedt [EMAIL PROTECTED] wrote:
 
  I spent the day chasing a bug that would hang PPC on boot up when 
  ftrace is configured in. I found that it was simply a stupid bug I did 
  to handle the non MCOUNT_RECORD case. Since I was testing only on x86, 
  and the MCOUNT_RECORD is automatically set for dynamic ftrace if it is 
  available, I did not test the case where MCOUNT_RECORD was not set.
  
  I have not finished porting MCOUNT_RECORD to PPC, but have found that 
  it has caused some issues for archs that do not support it yet.
  
  This patch series handles these cases.
 
 applied to tip/tracing/ftrace, thanks Steve.
 
 Are these two merged yet?  I just spent the better part of the morning
 trying to figure out why various Fedora kernels based on 2.6.27-rcX and
 2.6.27 final hung on my G5 and finally got one booting with FTRACE
 disabled.

My powerbook does not boot with ftrace enabled. I'm currently debugging 
it. When I get it working, you'll see patches.

Well, that's why I asked.  You sent 2 patches out over a month ago that
don't appear to have shown up in any Linus or PowerPC tree.

They will be to linux-tip though, and not for the current mainline (unless 
the code in linux-tip gets merged).

If linux-tip is some x86 topic branch, I think that's the wrong place for
fixes that are needed on non-x86 arches.

josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] [RESEND] i2c-cpm: Suppress autoprobing for devices

[Wolfram Sang]

Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove
automatic probing for this i2c controller. Might need updates to dts files
using it.

Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
Acked-by: Jochen Friedrich [EMAIL PROTECTED]
---
Resend with cc to i2c.

 drivers/i2c/busses/i2c-cpm.c |1 -
 1 file changed, 1 deletion(-)

Index: linux-2.6/drivers/i2c/busses/i2c-cpm.c
===
--- linux-2.6.orig/drivers/i2c/busses/i2c-cpm.c
+++ linux-2.6/drivers/i2c/busses/i2c-cpm.c
@@ -423,7 +423,6 @@ static const struct i2c_adapter cpm_ops 
.owner  = THIS_MODULE,
.name   = i2c-cpm,
.algo   = cpm_i2c_algo,
-   .class  = I2C_CLASS_HWMON | I2C_CLASS_SPD,
 };
 
 static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm)

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] i2c-cpm: Suppress autoprobing for devices

[David Miller]

From: Kumar Gala [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 11:09:30 -0500

 
 On Oct 16, 2008, at 6:13 AM, Wolfram Sang wrote:
 
 
  Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove
  automatic probing for this i2c controller. Might need updates to dts files
  using it.
 
  Signed-off-by: Wolfram Sang [EMAIL PROTECTED]
  ---
  drivers/i2c/busses/i2c-cpm.c |1 -
  1 file changed, 1 deletion(-)
 
 The i2c list should be CC'd.  Jean should pick this up.

Don't bother, he'll just argue with you about the fact that class
based probing should be maintained.

He's doing exactly that with me right now.

I think the powerpc folks are doing exactly the right thing by merging
their I2C changes directly to Linus.  Please just continue doing this.

That's what I should have done with my sparc stuff, I'm being punished
now for having sent my changes to the right place. :-/

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Modify sysfs gpio export so that value displays as 0 or 1

[David Brownell]

On Friday 10 October 2008, Steven A. Falco wrote:
 gpiolib can export GPIOs to userspace via sysfs.  This patch modifies
 the gpio_value_show() so that any non-zero value is explicitly printed
 as 1, rather than whatever numerical value the lower-level driver returns.
 
 Signed-off-by: Steve Falco sfalco at harris.com

I just forwarded this to Andrew (cc LKML) with my
signoff ... sorry I forgot to add you to the CC.  :(


 ---
 
 diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
 index 8d29405..36bf72b 100644
 --- a/drivers/gpio/gpiolib.c
 +++ b/drivers/gpio/gpiolib.c
 @@ -237,7 +237,7 @@ static ssize_t gpio_value_show(struct device *dev,
   if (!test_bit(FLAG_EXPORT, desc-flags))
   status = -EIO;
   else
 - status = sprintf(buf, %d\n, gpio_get_value_cansleep(gpio));
 + status = sprintf(buf, %d\n, !!gpio_get_value_cansleep(gpio));
  
   mutex_unlock(sysfs_lock);
   return status;
 
 


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[David Miller]

From: Johannes Berg [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 16:57:19 +0200

 On Wed, 2008-10-15 at 22:02 -0700, David Miller wrote:
  
  
   net/sched/sch_generic.c: In function 'dev_watchdog':
   net/sched/sch_generic.c:224: warning: unused variable 'drivername'
  
  Sucky, if WARN_ONCE() evaluates to nothing the sprintf() string buffer
  on the stack looks unused.
 
 I've complained about this to Arjan before, we actually lose all
 messages passed to WARN() or WARN_ONCE() on platforms that use bug traps
 for warnings too.

Ok I see how that works, yes, it should be fixed.

If the platform defines a __WARN (which powerpc does) the
whole format string and printf args go unevaluated, it's
because of the following sequence in asm-generic/bug.h:

#ifndef __WARN
#ifndef __ASSEMBLY__
extern void warn_on_slowpath(const char *file, const int line);
extern void warn_slowpath(const char *file, const int line,
const char *fmt, ...) __attribute__((format(printf, 3, 4)));
#define WANT_WARN_ON_SLOWPATH
#endif
#define __WARN() warn_on_slowpath(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
#else
#define __WARN_printf(arg...) __WARN()
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Arjan van de Ven]

On Thu, 16 Oct 2008 12:49:23 -0700 (PDT)
David Miller [EMAIL PROTECTED] wrote:
 #endif
 #define __WARN() warn_on_slowpath(__FILE__, __LINE__)
 #define __WARN_printf(arg...) warn_slowpath(__FILE__, __LINE__, arg)
 #else
 #define __WARN_printf(arg...) __WARN()

the easiest way I suppose would be to do

#define __WARN_printf(arg..) do { printk(arg); __WARN(); } while (0)

any obvious problems with this ?


-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] i2c-cpm: Suppress autoprobing for devices

[Wolfram Sang]

On Thu, Oct 16, 2008 at 12:23:25PM -0700, David Miller wrote:

 Don't bother, he'll just argue with you about the fact that class
 based probing should be maintained.
 
 He's doing exactly that with me right now.

I think the two of you talked at cross purposes. Just observing, I can
follow his point, that you can easily switch probing off in the driver
(like Wolfgang Grandegger's and my patch does), so there is no need to
sacrifice some functionality of a whole algorithm. Just clear the
.class-entry in your driver and there should be peace ;)

All the best,

   Wolfram

-- 
  Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry


signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] Add new framebuffer driver for Fujitsu MB862xx GDCs

[Andrew Morton]

On Tue, 14 Oct 2008 17:25:06 +0200
Anatolij Gustschin [EMAIL PROTECTED] wrote:

 This patch adds framebuffer driver for Fujitsu
 Carmine/Coral-P(A)/Lime graphics controllers.
 Lime GDC support is known to work on PPC440EPx
 based lwmon5 and MPC8544E based socrates embedded
 boards, both equipped with Lime GDC. Carmine/Coral-P
 PCI GDC support is known to work on PPC440EPx based
 Sequoia board and also on x86 platform.

Well I've read all the followup discussion and now I don't know what
to do.

I think I'll just merge it and see if anyone shouts at me.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Problems with PCI-E devices not being detected with switch

[Benjamin Herrenschmidt]

On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
 
 Thanks for your help.  I did try a 5s delay and other than the boot
 taking an extra couple of seconds, there was no change.  The messages
 above unknown header still showed up.  Downstream devices were not
 found.
 BTW, this is with both the Denx kernel tree and the official 2.6.27
 kernel.  
 Both have the same results. One added note, just to rule out bad
 electronics,
 I have confirmed that the switch+sata work correctly together if placed
 into a plain x86 pc with 2.6.24.  So the electronics are fine.

I think I know where the problem comes from. The bus numbers aren't
getting properly assigned below the root bus. I'm working on some test
patches, I'll let you know when I have something.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] powerpc and sparc: introduce dev_archdata node accessors

[David Miller]

From: Anton Vorontsov [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 21:12:51 +0400

 The name of the device_node field differ across the platforms, so we
 have to implement inlined accessors. This is needed to avoid ugly
 #ifdef in the generic code.
 
 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

I'm happy to just change this member name on sparc to match
powerpc's choice.

That being said, this abstraction still has value and I'd
like to let you merge this now and make forward progress
so:

Acked-by: David S. Miller [EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 1/7] powerpc and sparc: introduce dev_archdata node accessors

[Grant Likely]

On Thu, Oct 16, 2008 at 4:36 PM, David Miller [EMAIL PROTECTED] wrote:
 From: Anton Vorontsov [EMAIL PROTECTED]
 Date: Thu, 16 Oct 2008 21:12:51 +0400

 The name of the device_node field differ across the platforms, so we
 have to implement inlined accessors. This is needed to avoid ugly
 #ifdef in the generic code.

 Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]

 I'm happy to just change this member name on sparc to match
 powerpc's choice.

 That being said, this abstraction still has value and I'd
 like to let you merge this now and make forward progress
 so:

 Acked-by: David S. Miller [EMAIL PROTECTED]

I agree;

Acked-by: Grant Likely [EMAIL PROTECTED]



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: powerpc allmodconfig

[Jesse Brandeburg]

On Wed, Oct 15, 2008 at 11:58 PM, David Miller [EMAIL PROTECTED] wrote:
 There's already a completely different fix queued in netdev patchworks
 (for myri10ge only right now, to be duplicated for Intel drivers). The
 idea is to stop having almost-unrelated drivers select each other
 directly, let people select which drivers they really want, and have
 Kconfig handle modules/builtin-stuff correctly. See
 http://patchwork.ozlabs.org/patch/4506/

 Right, my plan was to duplicate this for the other drivers.

The work is already done for ixgbe and igb, and we have it in testing.
 It should be in your inbox today or tomorrow.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

RE: Problems with PCI-E devices not being detected with switch

[Benjamin Herrenschmidt]

On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
 Benjamin Herrenschmidt wrote:
  On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
  
  Note for people on CC: This is a problem on 460EX on a canyonland
  using the 4x port. 
  
  The problem occurs when Linux boots. It sees the switch (and looking
  in /sys/bus/... confirms it), but nothing on the downstream sides of
  the switch (secondary busses) is visible.  There were no boot
  messages to indicate it had seen the Sil 3531 and it doesn't
  function.  We've also tried other PCI-E devices (NI GPIB) on the
  downstream side and they are also not detected, so it seems to be
  something in Linux, my configuration, etc.  I've included the boot
  messages below from u-boot and the kernel.  It is more than just the
  pci boot messages, but I was not sure if something else in the log
  with provide some insight. 
  
  The messages below look really fishy indeed:

Ok, can you send me a full dmesg log with debug on the kernel command
line after adding a #define DEBUG 1 to the top of drivers/pci/probe.c
please ? (before the batch of #include).

The generic code is _supposed_ to somewhat figure out that bridges
haven't been setup by the firmware and fix that up, but for some reason
it's not happening I think. Or something else is wrong ...

Stefan, I could use the same log from your customer too.

Thanks,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] ftrace: powerpc: remove startup functions from tracing

[Steven Rostedt]

[
  Josh, can you see if this allows you to boot on PowerPC?
  It worked on my powerbook.
]

The early init code in PowerPC is not mapped to their final locations
and all jumps and memory references must be done with relative jumps
and accesses.

The lib files in the powerpc directory are called in early boot, and
since mcount will perform direct access to memory, the lib files need
not be traced.

Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
 arch/powerpc/lib/Makefile |5 +
 1 file changed, 5 insertions(+)

Index: linux-compile.git/arch/powerpc/lib/Makefile
===
--- linux-compile.git.orig/arch/powerpc/lib/Makefile2008-10-16 
19:26:39.0 -0400
+++ linux-compile.git/arch/powerpc/lib/Makefile 2008-10-16 19:26:49.0 
-0400
@@ -2,6 +2,11 @@
 # Makefile for ppc-specific library files..
 #
 
+ifdef CONFIG_FTRACE
+ORIG_CFLAGS := $(KBUILD_CFLAGS)
+KBUILD_CFLAGS = $(subst -pg,,$(ORIG_CFLAGS))
+endif
+
 ifeq ($(CONFIG_PPC64),y)
 EXTRA_CFLAGS   += -mno-minimal-toc
 endif


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ftrace: powerpc: remove startup functions from tracing

[Benjamin Herrenschmidt]

On Thu, 2008-10-16 at 20:48 -0400, Steven Rostedt wrote:
 
 The early init code in PowerPC is not mapped to their final locations
 and all jumps and memory references must be done with relative jumps
 and accesses.
 
 The lib files in the powerpc directory are called in early boot, and
 since mcount will perform direct access to memory, the lib files need
 not be traced.

This is annoying though, because that means things like memcpy,
copy_to_from_user etc... can't be traced. On the other hand a lot
of that is asm and already doesn't call mcount.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] ftrace: powerpc: remove startup functions from tracing

[Steven Rostedt]

On Fri, 17 Oct 2008, Benjamin Herrenschmidt wrote:

 On Thu, 2008-10-16 at 20:48 -0400, Steven Rostedt wrote:
  
  The early init code in PowerPC is not mapped to their final locations
  and all jumps and memory references must be done with relative jumps
  and accesses.
  
  The lib files in the powerpc directory are called in early boot, and
  since mcount will perform direct access to memory, the lib files need
  not be traced.
 
 This is annoying though, because that means things like memcpy,
 copy_to_from_user etc... can't be traced. On the other hand a lot
 of that is asm and already doesn't call mcount.

Yeah, I know. I was going to pick and choose which files in there should 
be converted, but then I saw that they were mostly asm, and it seemed to 
be better safe than sorry.

Sure, we could probably bring it down a bit. But I'm a bit paranoid it may 
cause someone else not to boot because of something else being called at 
early boot up.

But don't worry. When we get MCOUNT_RECORD ported to PPC this no longer 
becomes an issue, and we can simply do a
ifndef CONFIG_FTRACE_MCOUNT_RECORD around the -pg removal in the 
Makefile. (or what ever the Makefile syntax is for config options)

-- Steve

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH v3] powerpc: properly reserve in bootmem the lmb reserved regions that cross NUMA nodes

[Jon Tollefson]

Benjamin Herrenschmidt wrote:

On Thu, 2008-10-09 at 15:18 -0500, Jon Tollefson wrote:
  

If there are multiple reserved memory blocks via lmb_reserve() that are
contiguous addresses and on different NUMA nodes we are losing track of which 
address ranges to reserve in bootmem on which node.  I discovered this 
when I recently got to try 16GB huge pages on a system with more then 2 nodes.



I'm going to apply it, however, could you double check something for
me ? A cursory glance of the new version makes me wonder, what if the
first call to get_node_active_region() ends up with the work_fn never
hitting the if () case ? I think in that case, node_ar-end_pfn never
gets initialized right ? Can that happen in practice ? I suspect that
isn't the case but better safe than sorry...
  
I have tested this on a few machines and it hasn't been a problem.  But 
I don't see anything in lmb_reserve() that would prevent reserving a 
block that was outside of valid memory.  So to be safe I have attached a 
patch that checks for an empty active range.


I also noticed that the size to reserve for subsequent nodes for a 
reserve that spans nodes wasn't taking into account the amount reserved 
on previous nodes so the patch addresses that too.  If you would prefer 
this be a separate patch let me know.



If there's indeed a potential problem, please send a fixup patch.

Cheers,
Ben.
  

Adjust amount to reserve based on previous nodes for reserves spanning
multiple nodes. Check if the node active range is empty before attempting
to pass the reserve to bootmem.  In practice the range shouldn't be empty,
but to be sure we check.

Signed-off-by: Jon Tollefson [EMAIL PROTECTED]
---


arch/powerpc/mm/numa.c |   15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)


diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 6cf5c71..195bfcd 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -116,6 +116,7 @@ static int __init get_active_region_work_fn(unsigned long 
start_pfn,

/*
 * get_node_active_region - Return active region containing start_pfn
+ * Active range returned is empty if none found.
 * @start_pfn: The page to return the region for.
 * @node_ar: Returned set to the active region containing start_pfn
 */
@@ -126,6 +127,7 @@ static void __init get_node_active_region(unsigned long 
start_pfn,

node_ar-nid = nid;
node_ar-start_pfn = start_pfn;
+   node_ar-end_pfn = start_pfn;
work_with_active_regions(nid, get_active_region_work_fn, node_ar);
}

@@ -933,18 +935,20 @@ void __init do_init_bootmem(void)
struct node_active_region node_ar;

get_node_active_region(start_pfn, node_ar);
-   while (start_pfn  end_pfn) {
+   while (start_pfn  end_pfn 
+   node_ar.start_pfn  node_ar.end_pfn) {
+   unsigned long reserve_size = size;
/*
 * if reserved region extends past active region
 * then trim size to active region
 */
if (end_pfn  node_ar.end_pfn)
-   size = (node_ar.end_pfn  PAGE_SHIFT)
+   reserve_size = (node_ar.end_pfn  PAGE_SHIFT)
- (start_pfn  PAGE_SHIFT);
-   dbg(reserve_bootmem %lx %lx nid=%d\n, physbase, size,
-   node_ar.nid);
+   dbg(reserve_bootmem %lx %lx nid=%d\n, physbase,
+   reserve_size, node_ar.nid);
reserve_bootmem_node(NODE_DATA(node_ar.nid), physbase,
-   size, BOOTMEM_DEFAULT);
+   reserve_size, BOOTMEM_DEFAULT);
/*
 * if reserved region is contained in the active region
 * then done.
@@ -959,6 +963,7 @@ void __init do_init_bootmem(void)
 */
start_pfn = node_ar.end_pfn;
physbase = start_pfn  PAGE_SHIFT;
+   size = size - reserve_size;
get_node_active_region(start_pfn, node_ar);
}





___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH 0/2] ftrace: fixes for PPC

[Chris Friesen]

Josh Boyer wrote:

 Are these two merged yet?  I just spent the better part of the morning
 trying to figure out why various Fedora kernels based on 2.6.27-rcX and
 2.6.27 final hung on my G5 and finally got one booting with FTRACE
 disabled.

Until recently I could boot my G5 with FTRACE enabled, but it totally screwed 
up load balancing.


As of a couple days ago, -tip hung on boot due to the following genirq 
issue:



diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 570d1ea..1c178ae 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -132,7 +132,7 @@ int set_irq_type(unsigned int irq, unsigned int type)
return 0;

spin_lock_irqsave(desc-lock, flags);
-   ret = __irq_set_trigger(desc, irq, flags);
+   ret = __irq_set_trigger(desc, irq, type);
spin_unlock_irqrestore(desc-lock, flags);
return ret;
   }



Chris

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev