RE: [PATCH v1] ppc44x:PHY fixup for USB on canyonlands board
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
>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_*()
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 +- arch/powerpc/
Re: RFC: Mega rename of device tree routines from of_*() to dt_*()
On Wed, Nov 24, 2010 at 8:03 AM, Michael Ellerman 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_*()
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_*()
> -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_*()
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_*()
On Wed, Nov 24, 2010 at 10:18 AM, David Daney 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_*()
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_*()
> -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
