RE: [PATCH v1] ppc44x:PHY fixup for USB on canyonlands board

2010-11-24 Thread Benjamin Herrenschmidt
On Wed, 2010-11-24 at 10:25 +0530, Rupjyoti Sarmah wrote:
 
 So, do you suggest to move this macro to the canyonlands.c ? Or
 introduce
 canyonlands.h ?

Just move it to the .c file.

Cheers,
Ben.


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


RE: ucc_geth: transmit queue timeout at half-duplex mode

2010-11-24 Thread Li Yang-R58472
Subject: ucc_geth: transmit queue timeout at half-duplex mode

Hi all,
on my MPC8321E with linux-2.6.36 I get this netdev watchdog warning
NETDEV WATCHDOG: eth0 (of:ucc_geth): transmit queue 0 timed out if the
link mode is half-duplex.
The warning is caused, because all Tx BDs are full and packet transmission
is stopped with netif_stop_queue() in ucc_geth_start_xmit().

You can reproduce the bug in the following way:
- Connect to a switch, that supports only 10baseT, or set the mode
manually with mii-diag -F 10baseT.
- Open a telnet session to the target. Generate higher traffic with
executing maybe cat /proc/interrupts many times.
- After some tries the ethernet connection will be down, then again after
approx. 30s seconds the netdev watchdog will dump the warning.

It is unclear to me why the TxBDs get full. Due to missing Tx buffer
sent interrupts, it seems that the QE stops the transmission.

I found some issue in the errata: QE_ENET20: UEC may stop transmitting
after late collision. But UCCE[TXE] is never set in this case.

Thank you for your help in advance and best regards,

I believe your problem is related to an errata for 8321:
High Tx Virtual FIFO threshold size can cause UCC to halt.

Reducing the UTFTT might fix the problem.

If you are interested, I can sent you the detailed errata off the thread.

- Leo


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


RFC: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread Michael Ellerman
Hi all,

There were some murmurings on IRC last week about renaming the of_*()
routines. I was procrastinating at the time and said I'd have a look at
it, so here I am.

The thinking is that on many platforms that use the of_() routines
OpenFirmware is not involved at all, this is true even on many powerpc
platforms. Also for folks who don't know the OpenFirmware connection it
reads as of, as in a can of worms.

Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
it would be nice to get rid of, but it's a lot of churn.

So I'm hoping people with either say YES this is a great idea, or NO
this is stupid.

As step one I've just renamed as many routines as I could find to see
what the resulting patch looks like, so we can quantify the churn. I
also did device.of_node, which is used quite a bit.

Thoughts?

of - dt most places I could think of (done mechanically):

 Documentation/powerpc/booting-without-of.txt   |2 +-
 arch/microblaze/include/asm/cpuinfo.h  |2 +-
 arch/microblaze/include/asm/prom.h |   12 +-
 arch/microblaze/kernel/cpu/cpuinfo.c   |2 +-
 arch/microblaze/kernel/head.S  |2 +-
 arch/microblaze/kernel/heartbeat.c |6 +-
 arch/microblaze/kernel/intc.c  |8 +-
 arch/microblaze/kernel/irq.c   |6 +-
 arch/microblaze/kernel/prom.c  |   38 ++--
 arch/microblaze/kernel/prom_parse.c|   28 ++--
 arch/microblaze/kernel/reset.c |   12 +-
 arch/microblaze/kernel/setup.c |6 +-
 arch/microblaze/kernel/timer.c |   10 +-
 arch/microblaze/pci/pci-common.c   |   26 ++--
 arch/microblaze/pci/pci_32.c   |   34 ++--
 arch/microblaze/pci/xilinx_pci.c   |   14 +-
 arch/microblaze/platform/platform.c|6 +-
 arch/mips/kernel/prom.c|   32 ++--
 arch/powerpc/boot/of.c |2 +-
 arch/powerpc/boot/ofconsole.c  |2 +-
 arch/powerpc/boot/oflib.c  |2 +-
 arch/powerpc/include/asm/cpm.h |2 +-
 arch/powerpc/include/asm/ibmebus.h |4 +-
 arch/powerpc/include/asm/irq.h |8 +-
 arch/powerpc/include/asm/kvm_para.h|6 +-
 arch/powerpc/include/asm/macio.h   |6 +-
 arch/powerpc/include/asm/msi_bitmap.h  |6 +-
 arch/powerpc/include/asm/parport.h |6 +-
 arch/powerpc/include/asm/pmac_feature.h|2 +-
 arch/powerpc/include/asm/prom.h|   16 +-
 arch/powerpc/kernel/btext.c|   28 ++--
 arch/powerpc/kernel/cacheinfo.c|   20 +-
 arch/powerpc/kernel/dma-swiotlb.c  |2 +-
 arch/powerpc/kernel/ibmebus.c  |   38 ++--
 arch/powerpc/kernel/irq.c  |   22 +-
 arch/powerpc/kernel/isa-bridge.c   |   14 +-
 arch/powerpc/kernel/kvm.c  |6 +-
 arch/powerpc/kernel/legacy_serial.c|  104 +-
 arch/powerpc/kernel/lparcfg.c  |   24 +-
 arch/powerpc/kernel/machine_kexec.c|   12 +-
 arch/powerpc/kernel/machine_kexec_64.c |   16 +-
 arch/powerpc/kernel/of_platform.c  |   24 +-
 arch/powerpc/kernel/pci-common.c   |   24 +-
 arch/powerpc/kernel/pci_32.c   |   34 ++--
 arch/powerpc/kernel/pci_64.c   |6 +-
 arch/powerpc/kernel/pci_dn.c   |6 +-
 arch/powerpc/kernel/pci_of_scan.c  |   22 +-
 arch/powerpc/kernel/proc_powerpc.c |2 +-
 arch/powerpc/kernel/prom.c |   92 +-
 arch/powerpc/kernel/prom_parse.c   |   28 ++--
 arch/powerpc/kernel/rtas-proc.c|6 +-
 arch/powerpc/kernel/rtas.c |   34 ++--
 arch/powerpc/kernel/rtas_pci.c |   22 +-
 arch/powerpc/kernel/setup-common.c |   58 +++---
 arch/powerpc/kernel/setup_32.c |4 +-
 arch/powerpc/kernel/setup_64.c |   24 +-
 arch/powerpc/kernel/smp.c  |   14 +-
 arch/powerpc/kernel/time.c |8 +-
 arch/powerpc/kernel/vio.c  |   80 
 arch/powerpc/mm/hash_native_64.c   |6 +-
 arch/powerpc/mm/hash_utils_64.c|   26 ++--
 arch/powerpc/mm/numa.c |   62 +++---
 arch/powerpc/platforms/40x/ep405.c |   16 +-
 arch/powerpc/platforms/40x/hcu4.c  |   10 +-
 arch/powerpc/platforms/40x/ppc40x_simple.c |   10 +-
 

Re: RFC: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread Timur Tabi
On Wed, Nov 24, 2010 at 8:03 AM, Michael Ellerman
mich...@ellerman.id.au wrote:

 Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
 it would be nice to get rid of, but it's a lot of churn.

 So I'm hoping people with either say YES this is a great idea, or NO
 this is stupid.

Well, my vote is no.  I wouldn't call it stupid, but I do think it's
a bad idea.

In general, I don't like renaming functions, because it causes
complications with merges and porting code across kernel versions.  It
also forces me to re-remember things.

And especially in this case, the churn is too great.  You're affecting
files across multiple subsystems and architectures.

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: RFC: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread David Daney

On 11/24/2010 06:03 AM, Michael Ellerman wrote:

Hi all,

There were some murmurings on IRC last week about renaming the of_*()
routines. I was procrastinating at the time and said I'd have a look at
it, so here I am.

The thinking is that on many platforms that use the of_() routines
OpenFirmware is not involved at all, this is true even on many powerpc
platforms. Also for folks who don't know the OpenFirmware connection it
reads as of, as in a can of worms.

Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
it would be nice to get rid of, but it's a lot of churn.

So I'm hoping people with either say YES this is a great idea, or NO
this is stupid.

As step one I've just renamed as many routines as I could find to see
what the resulting patch looks like, so we can quantify the churn. I
also did device.of_node, which is used quite a bit.

Thoughts?

of -  dt most places I could think of (done mechanically):


[...]

  drivers/of/address.c   |  114 ++--
  drivers/of/base.c  |   14 +-
  drivers/of/device.c|   36 ++--
  drivers/of/fdt.c   |4 +-
  drivers/of/gpio.c  |   32 ++--
  drivers/of/irq.c   |4 +-
  drivers/of/of_i2c.c|   18 +-
  drivers/of/of_mdio.c   |   16 +-
  drivers/of/of_spi.c|   12 +-
  drivers/of/pdt.c   |4 +-
  drivers/of/platform.c  |  212 ++--


Well, not that I care one way or the other, but for consistency you 
should change all these directory and file names as well.


David Daney

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


RE: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread Stephen Neuendorffer


 -Original Message-
 From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org 
 [mailto:linuxppc-dev-
 bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Michael 
 Ellerman
 Sent: Wednesday, November 24, 2010 6:04 AM
 To: LKML
 Cc: linux-mips; microblaze-ucli...@itee.uq.edu.au; 
 devicetree-disc...@lists.ozlabs.org; linuxppc-dev
 list; sparcli...@vger.kernel.org
 Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()
 
 Hi all,
 
 There were some murmurings on IRC last week about renaming the of_*()
 routines. I was procrastinating at the time and said I'd have a look at
 it, so here I am.
 
 The thinking is that on many platforms that use the of_() routines
 OpenFirmware is not involved at all, this is true even on many powerpc
 platforms. Also for folks who don't know the OpenFirmware connection it
 reads as of, as in a can of worms.
 
 Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
 it would be nice to get rid of, but it's a lot of churn.
 
 So I'm hoping people with either say YES this is a great idea, or NO
 this is stupid.

Personally, I think it's a great idea, if only because I stared long and hard
at the code once upon a time trying to figure out what is really OF-related
and what isn't.  It's somewhat clearer now that drivers/of has been factored
out (although, shouldn't it be drivers/dt???)

That said, it *is* alot of code churn.  If it's going to be done, I think it 
should be
done in concert with fixing a bunch of the function names which don't really 
follow any
sane naming convention, so that the backporting discontinuity only happens once.

Steve

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread David Daney

On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:




-Original Message-
From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org 
[mailto:linuxppc-dev-
bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Michael 
Ellerman
Sent: Wednesday, November 24, 2010 6:04 AM
To: LKML
Cc: linux-mips; microblaze-ucli...@itee.uq.edu.au; 
devicetree-disc...@lists.ozlabs.org; linuxppc-dev
list; sparcli...@vger.kernel.org
Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()

Hi all,

There were some murmurings on IRC last week about renaming the of_*()
routines. I was procrastinating at the time and said I'd have a look at
it, so here I am.

The thinking is that on many platforms that use the of_() routines
OpenFirmware is not involved at all, this is true even on many powerpc
platforms. Also for folks who don't know the OpenFirmware connection it
reads as of, as in a can of worms.

Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
it would be nice to get rid of, but it's a lot of churn.

So I'm hoping people with either say YES this is a great idea, or NO
this is stupid.


Personally, I think it's a great idea, if only because I stared long and hard
at the code once upon a time trying to figure out what is really OF-related
and what isn't.  It's somewhat clearer now that drivers/of has been factored
out (although, shouldn't it be drivers/dt???)

That said, it *is* alot of code churn.  If it's going to be done, I think it 
should be
done in concert with fixing a bunch of the function names which don't really 
follow any
sane naming convention, so that the backporting discontinuity only happens once.



Oh, you mean things like:

of_{,un}register_platform_driver vs. platform_driver_{,un}register

That one is particularly annoying to me.

David Daney
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread Grant Likely
On Wed, Nov 24, 2010 at 10:18 AM, David Daney dda...@caviumnetworks.com wrote:
 On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:


 -Original Message-
 From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
 [mailto:linuxppc-dev-
 bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Michael
 Ellerman
 Sent: Wednesday, November 24, 2010 6:04 AM
 To: LKML
 Cc: linux-mips; microblaze-ucli...@itee.uq.edu.au;
 devicetree-disc...@lists.ozlabs.org; linuxppc-dev
 list; sparcli...@vger.kernel.org
 Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()

 Hi all,

 There were some murmurings on IRC last week about renaming the of_*()
 routines. I was procrastinating at the time and said I'd have a look at
 it, so here I am.

 The thinking is that on many platforms that use the of_() routines
 OpenFirmware is not involved at all, this is true even on many powerpc
 platforms. Also for folks who don't know the OpenFirmware connection it
 reads as of, as in a can of worms.

 Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
 it would be nice to get rid of, but it's a lot of churn.

 So I'm hoping people with either say YES this is a great idea, or NO
 this is stupid.

 Personally, I think it's a great idea, if only because I stared long and
 hard
 at the code once upon a time trying to figure out what is really
 OF-related
 and what isn't.  It's somewhat clearer now that drivers/of has been
 factored
 out (although, shouldn't it be drivers/dt???)

Yes, the directory name should change, as should the CONFIG_OF* defines.


 That said, it *is* alot of code churn.  If it's going to be done, I think
 it should be
 done in concert with fixing a bunch of the function names which don't
 really follow any
 sane naming convention, so that the backporting discontinuity only happens
 once.


 Oh, you mean things like:

 of_{,un}register_platform_driver vs. platform_driver_{,un}register

 That one is particularly annoying to me.

Ignore that one.  of_{,un}platform_driver is deprecated and users will
all be converted to platform_drivers.

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


Re: RFC: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread David VomLehn
On Thu, Nov 25, 2010 at 01:03:33AM +1100, Michael Ellerman wrote:
 Hi all,
 
 There were some murmurings on IRC last week about renaming the of_*()
 routines. I was procrastinating at the time and said I'd have a look at
 it, so here I am.
 
 The thinking is that on many platforms that use the of_() routines
 OpenFirmware is not involved at all, this is true even on many powerpc
 platforms. Also for folks who don't know the OpenFirmware connection it
 reads as of, as in a can of worms.
 
 Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
 it would be nice to get rid of, but it's a lot of churn.
 
 So I'm hoping people with either say YES this is a great idea, or NO
 this is stupid.
 
 As step one I've just renamed as many routines as I could find to see
 what the resulting patch looks like, so we can quantify the churn. I
 also did device.of_node, which is used quite a bit.
 
 Thoughts?

I'm looking at it the other way. There are inconsistencies in naming of
symbols and files we definitely should clean up. Since we're doing that,
let's take the opportunity to move from of* to dt*. With multiple
architectures adding device tree support, this is about the last chance
to do this without impacting too many people.
-- 
David VL
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


RE: Mega rename of device tree routines from of_*() to dt_*()

2010-11-24 Thread Stephen Neuendorffer


 -Original Message-
 From: David Daney [mailto:dda...@caviumnetworks.com]
 Sent: Wednesday, November 24, 2010 9:18 AM
 To: Stephen Neuendorffer
 Cc: mich...@ellerman.id.au; LKML; linux-mips; 
 microblaze-ucli...@itee.uq.edu.au; devicetree-
 disc...@lists.ozlabs.org; linuxppc-dev list; sparcli...@vger.kernel.org
 Subject: Re: Mega rename of device tree routines from of_*() to dt_*()
 
 On 11/24/2010 09:02 AM, Stephen Neuendorffer wrote:
 
 
  -Original Message-
  From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org 
  [mailto:linuxppc-dev-
  bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Michael 
  Ellerman
  Sent: Wednesday, November 24, 2010 6:04 AM
  To: LKML
  Cc: linux-mips; microblaze-ucli...@itee.uq.edu.au; 
  devicetree-disc...@lists.ozlabs.org; linuxppc-
 dev
  list; sparcli...@vger.kernel.org
  Subject: RFC: Mega rename of device tree routines from of_*() to dt_*()
 
  Hi all,
 
  There were some murmurings on IRC last week about renaming the of_*()
  routines. I was procrastinating at the time and said I'd have a look at
  it, so here I am.
 
  The thinking is that on many platforms that use the of_() routines
  OpenFirmware is not involved at all, this is true even on many powerpc
  platforms. Also for folks who don't know the OpenFirmware connection it
  reads as of, as in a can of worms.
 
  Personally I'm a bit ambivalent about it, the OF name is a bit wrong so
  it would be nice to get rid of, but it's a lot of churn.
 
  So I'm hoping people with either say YES this is a great idea, or NO
  this is stupid.
 
  Personally, I think it's a great idea, if only because I stared long and 
  hard
  at the code once upon a time trying to figure out what is really OF-related
  and what isn't.  It's somewhat clearer now that drivers/of has been factored
  out (although, shouldn't it be drivers/dt???)
 
  That said, it *is* alot of code churn.  If it's going to be done, I think 
  it should be
  done in concert with fixing a bunch of the function names which don't 
  really follow any
  sane naming convention, so that the backporting discontinuity only happens 
  once.
 
 
 Oh, you mean things like:
 
 of_{,un}register_platform_driver vs. platform_driver_{,un}register
 
 That one is particularly annoying to me.
 
 David Daney

Actually, I was particularly thinking of drivers/of/fdt.c, which I was recently 
hacking around with,
but I'm sure there are others... :)

Steve

This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev