* [PATCH 0/5] ehca: MR large page, small queue and fixes
From: Hoang-Nam Nguyen @ 2007-07-20 13:48 UTC (permalink / raw)
To: rolandd, linux-kernel, linuxppc-dev, openib-general
Cc: fenkes, raisch, stefan.roscher
Here is a patch set against Roland's git, branch for-2.6.23 for ehca.
It adds support for MR large page and small queues. In addition of that
it also contains various small fixes from previous comments and what
we found.
They are in details:
[1/5] adds support for MR large page
[2/5] generates event when SRQ limit reached
[3/5] makes ehca2ib_return_code() non inline
[4/5] makes internal_create/destroy_qp() static
[5/5] adds support for small queues
The patches should apply cleanly, in order, against Roland's git. Please
review the changes and apply the patches if they are okay.
Regards,
Nam & Stefan
^ permalink raw reply
* Re: Kmalloc returns which address
From: Alessandro Rubini @ 2007-07-20 12:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11705981.post@talk.nabble.com>
Hello.
> In linux kmelloc returns the pointer to virtual address not the physical
> address, to return to the physical address there is different function
> called ioremap
Not exactly. Both return virtual addresses. The kmalloc one is allocated
RAM memory, the ioremap is the virtual address built for you to
access a physical address you specified (i.e., a device memory area).
>> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and
>> pass
>> the pointer to hardware. Can I pass the pointer returned kmalloc? or I
>> should convert it into physical address?
If you allocate with kmalloc, use __pa(addr) to turn the virtual
address addr into the physical address you need to pass to the device,
ad DMA access is outside of the virtual view of the address space.
However, please note that according to how your device is connected
and what bus it is using, the design can get more hairy, you may need
to study the consistent memory allocations.
Hope this helps
/alessandro
^ permalink raw reply
* RE: How to access physical memory from user space for MPC8260 chip
From: Misbah khan @ 2007-07-20 11:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <0B45E93C5FF65740AEAE690BF3848B7A4AB178@rennsmail04.eu.thmulti.com>
Physical address you can map to kernel space using ioremap() function
but you are not clear whether you want to map it to the user space / kernel
space. To map kernel space to user space you should use mmap() functionality
in your driver.
I hope you got the answer to what you were expecting else send the clear
query
regard
misbah
Fillod Stephane wrote:
>
> suresh suresh wrote:
>>I have to map physical memory to user space or kernel space. I am
> writing >driver for MPC8260 chip and I want to know how to map any
> 32-bit address >space to user space and kernel space.
>
> Your question is a linuxppc-embedded FAQ. User-land access is documented
>
> in Denx's FAQ[1], and accessible through shorter URL[2]. For more
> information, please follow this thread[3] (not ppc specific actually).
>
> [1]
> http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acce
> ssingPeripheralsFromUserSpace
> [2] http://tinyurl.com/6c7th
> [3] http://article.gmane.org/gmane.linux.ports.ppc.embedded/5053
>
> In kernel land, ioremap() is all you need.
>
> Don't forget to use the 'eieio' asm instruction if you want explicit
> I/O ordering.
>
> Best Regards,
> --
> Stephane, the userland ioremap bot
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/How-to-access-physical-memory-from-user-space-for-MPC8260-chip-tf4067159.html#a11706536
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] powerpc: mpc5200 low power mode, .globl fix
From: Domen Puncer @ 2007-07-20 10:55 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: Linux PPC Mailing List, Paul Mackerras
In-Reply-To: <11847043512142-git-send-email-tnt@246tNt.com>
flush_data_cache doesn't need to be global, and can cause problems.
Thanks to Milton Miller for noticing this.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
arch/powerpc/platforms/52xx/lite5200_sleep.S | 1 -
1 file changed, 1 deletion(-)
Index: work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
===================================================================
--- work-powerpc.git.orig/arch/powerpc/platforms/52xx/lite5200_sleep.S
+++ work-powerpc.git/arch/powerpc/platforms/52xx/lite5200_sleep.S
@@ -400,7 +400,6 @@ restore_regs:
* Flush data cache
* Do this by just reading lots of stuff into the cache.
*/
- .globl flush_data_cache
flush_data_cache:
lis r3,CONFIG_KERNEL_START@h
ori r3,r3,CONFIG_KERNEL_START@l
^ permalink raw reply
* Re: Kmalloc returns which address
From: Misbah khan @ 2007-07-20 10:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e5eb93010707160659m6a7d0b02p623542739d28ab29@mail.gmail.com>
hi Suresh
In linux kmelloc returns the pointer to virtual address not the physical
address, to return to the physical address there is different function
called ioremap
for eg :-
char *buf_tx =kmalloc(100,GFP_KERNEL); // Tx buffer
char *buf_rx=kmalloc(100,GFP_KERNEL); // Rx buffer
ptr_tx=ioremap( buf_tx,100);
ptr_rx=ioremap(buf_rx,100);
To learn more about this go through Linux device driver by rubini
I hope this will work for you
regard
Misbah
suresh suresh wrote:
>
> Hi,
>
> I am porting MPC8280 driver from vxWorks to Linux.
>
> I want know the address return by kmalloc function? is it physical address
> or kernel virtual address.
>
> For Tx and Rx, hardware uses buffers, so I have to allocate buffers and
> pass
> the pointer to hardware. Can I pass the pointer returned kmalloc? or I
> should convert it into physical address?
>
> If it returns kernel virtual address, then how to convert into physical?
>
> Thanks & Regards-
> Suresh
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/Kmalloc-returns-which-address-tf4086826.html#a11705981
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Problem faced while using workqueue in the character driver.
From: Misbah khan @ 2007-07-20 10:40 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working on a character driver for FPGA, in which i am using a blocked
read call on workqueue. The read call will be unblocked by the Interrupt
from the Fpga to PPC Cpu.
The problem is that if the process is in blocked mode and then an Interrupt
occurs the system gives kernel Panic where as it get unblocked and start
reading the data but very soon it gets crashed.
Please send me your suggessins regarding the mentioned problem.
Thanks in advance
with regard
Misbah
--
View this message in context: http://www.nabble.com/Problem-faced-while-using-workqueue-in-the-character-driver.-tf4116327.html#a11705912
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: ML403 Hard TEMAC, PLB and Linux 2.6
From: Mohammad Sadegh Sadri @ 2007-07-20 9:27 UTC (permalink / raw)
To: Rick Moleres, linux-ppc; +Cc: linuxppc-embedded
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb2312", Size: 10777 bytes --]
Dear Massimiliano
Well I do not know the solution to the problem, but just,
In your post, there is some thing interesting for me,
How could you implement such large circuit on one FX12 FPGA?
We have done many experineces with both of AVNET MM and ML403,
you have, DDR SDRAM Controller, GPIO, UART, SYSACE and two intances of Tri-mode TEMAC GMII,
In our tests, with one instance of Tri mode TEMAC and UART and DDR controller, the whole FPGA resource were consumed we could not even put sysace interface.
For me, another important question is, how many PHY chips are available on your board? Each of Tri-mode temac modules are connected to a separate phy chip, yes?
________________________________
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Date: Thu, 19 Jul 2007 09:00:33 -0600
> From: Rick.Moleres@xilinx.com
> To: linux-ppc@eurotel.it
> CC: eemingliu@hotmail.com; linuxppc-embedded@ozlabs.org; mamsadegh@hotmail.com
>
> Hi,
> The first thing I would try is to make sure eth1 comes up without first bringing up eth0. In other words, does it come up independently? If not, there could be something wrong with its configuration in the kernel or perhaps a hardware design issue. If both interfaces come up independently, but not together, then there¡¯s likely a driver issue as we have not tested dual channel TEMAC with the Linux plb_temac driver. Perhaps others on the list have. The areas that I would look at would be: make sure each interface is getting a unique and correct PHY address; make sure any calls to the shared registers of the two channels are protected with semaphores/spinlocks. For example, I¡¯m pretty sure the PHY registers are shared, so any PHY accesses should be protected. I would think other Xilinx driver accesses like Start/Stop/Reset/Get or SetOptions/etc¡ should be protected as they may access shared registers.
> -Rick
> ________________________________
> From: Massimiliano.Patriarca@eurotel.it [mailto:Massimiliano.Patriarca@eurotel.it] On Behalf Of linux-ppc@eurotel.it
> Sent: Thursday, July 19, 2007 7:51 AM
> To: Rick Moleres
> Cc: Ming Liu; linuxppc-embedded@ozlabs.org; linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org; mamsadegh@hotmail.com
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi, we are trying to use both side of an hard temac + 2 plb temac in a Virtex4FX12 project.
> we succesfull implemented a single temac Montavista tree with eth0.
> when trying to use both temac, devices are correctly registered with kernel-
> eth0 comes up and working ok-
> when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without any error or info in the console
> # dmesg
> Linux version 2.6.10_mvl401-ml40x (massimiliano@linux-yhbz) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18 12:20:43 CEST 2007
> Eurotel motherboard init
> Port by MontaVista Software, Inc. (source@mvista.com)
> On node 0 totalpages: 7812
> DMA zone: 7812 pages, LIFO batch:1
> Normal zone: 0 pages, LIFO batch:1
> HighMem zone: 0 pages, LIFO batch:1
> Built 1 zonelists
> Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off
> Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFF000
> PID hash table entries: 128 (order: 7, 2048 bytes)
> hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627
> Console: colour dummy device 80x25
> Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
> Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k highmem)
> Calibrating delay loop... 252.92 BogoMIPS (lpj=126464)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> spawn_desched_task(00000000)
> desched cpu_callback 3/00000000
> ksoftirqd started up.
> desched cpu_callback 2/00000000
> desched thread 0 started up.
> NET: Registered protocol family 16
> Registering platform device 'xilinx_temac.0'. Parent at platform
> Registering platform device 'xilinx_temac.1'. Parent at platform
> Registering platform device 'xilinx_sysace.0'. Parent at platform
> Registering platform device 'xilinx_gpio.0'. Parent at platform
> Registering platform device 'xilinx_gpio.1'. Parent at platform
> Registering platform device 'oled_fb.0'. Parent at platform
> Generic PHY: Registered new driver
> oled_fb: 4096 video memory mapped to c2011000
> Console: switching to colour frame buffer device 16x8
> xgpio #0 at 0x40000000 mapped to 0xC2020000
> xgpio #1 at 0x40020000 mapped to 0xC2040000
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
> loop: loaded (max 8 devices)
> elevator: using anticipatory as default io scheduler
> System ACE at 0x41800000 mapped to 0xC2060000, irq=4, 1000944KB
> xsysace: xsysace1 xsysace2
> Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
> XTemac: using FIFO direct interrupt driven mode.
> eth0: Xilinx TEMAC #0 at 0x20000000 mapped to 0xC2080000, irq=0
> eth0: XTemac id 1.0f, block id 5, type 8
> XTemac: using FIFO direct interrupt driven mode.
> eth1: Xilinx TEMAC #1 at 0x20010000 mapped to 0xC20A0000, irq=10
> eth1: XTemac id 1.0f, block id 5, type 8
> i2c /dev entries driver
> i2c-xil_custom: registered with I2C (0)
> i2c-xil_custom: registered with I2C (1)
> mice: PS/2 mouse device common for all mice
> NET: Registered protocol family 2
> IP: routing cache hash table of 512 buckets, 4Kbytes
> TCP: Hash tables configured (established 2048 bind 4096)
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
> kjournald starting. Commit interval 5 seconds
> EXT3 FS on xsysace2, internal journal
> EXT3-fs: recovery complete.
> EXT3-fs: mounted filesystem with ordered data mode.
> VFS: Mounted root (ext3 filesystem).
> Freeing unused kernel memory: 124k init
> eth0: XTemac: Options: 0xb8f2
> eth0: XTemac: speed set to 100Mb/s
> eth0: XTemac: PHY Link carrier lost.
> # /sbin/ifconfig eth1 up
> # eth1: XTemac: Options: 0xb8f2
> Any suggestion?
> "Rick Moleres"
> Sent by: linuxppc-embedded-bounces+linux-ppc=eurotel.it@ozlabs.org
> 08/02/2007 17.23
> To
> "Ming Liu" ,
> cc
> linuxppc-embedded@ozlabs.org
> Subject
> RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2 as part of the BSP and Libraries generation for Linux 2.6. Note that we made a recent fix for better PHY address detection and speed negotiation. I've attached the adapter here, and it will be available in EDK 9.1.1 when that's released.
> Thanks,
> Rick
> -----Original Message-----
> From: linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org [mailto:linuxppc-embedded-bounces+moleres=xilinx.com@ozlabs.org] On Behalf Of Ming Liu
> Sent: Thursday, February 08, 2007 2:31 AM
> To: mamsadegh@hotmail.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> Hi,
> In xapp902, they are using the old cores for Temac. So it will be easier to
> generate a project in EDK 8.2. Not only the cores there are new, but also
> it can generate the driver for linux 2.6.
> BR
> Ming
> >From: Mohammad Sadegh Sadri
> >To:
> >CC: linuxppc-embedded@ozlabs.org
> >Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6
> >Date: Thu, 8 Feb 2007 07:13:47 +0000
> >
> >
> >Hi
> >Thanks for reply
> >Well, regarding xapp902, there is a very simple question, Where can I find
> it? It seems that Xilinx has deleted all of the links to these files.
> >
> >
> >
> >
> >
> >----------------------------------------
> > > Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6
> > > From: christophe.alayrac@cresitt.com
> > > To: mamsadegh@hotmail.com
> > > CC: linuxppc-embedded@ozlabs.org
> > > Date: Thu, 8 Feb 2007 06:51:45 +0100
> > >
> > > Le mercredi 07 février 2007 ?22:30 +0000, Mohammad Sadegh Sadri a
> > > écrit :
> > > Hi Mohammad,
> > >
> > > Please find here after some answer
> > >
> > > > 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there any
> ready to use design, or any reference design available for this?
> > > > I'm using EDK 8.1 and I understood that, when I choose the ML403
> board , EDK does not use hard temac, so , should I add it manually? ( well
> this is funny, but the wizard does not use hard temac , is it true? )
> > > > Is there any ready EDK projects for ML403, with TEMAC and PLB TEMAC
> modules already inserted and cofigured? (I don't want to use GSRD ) ( If
> yes would you please put the link here )
> > > >
> > > You can start from XAPP 902 from Xilinx, this design demonstrate TEMAC
> > > use in loopback mode. Some memers from that community have tried from
> > > that design as a starting point. I did not nknow if the succeed.
> > > I would recommand to get EDK 8.2 SP2 and use the Wizard to build a new
> > > design with TEMAC.
> > >
> > > > 2- Simply, Is there any driver available for linux 2.6 , for PLB
> TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I
> can download it?
> > > >
> > > For the kernel you can get it from Montavista source code site using
> GIT
> > > to download it (linux-xilinx-26). This is 2.6.17.4 version (last week!)
> > >
> > > Then you will need to pacth the Kernel with TEMAC drivers (look for
> > > TEMAC PAULUS MVISTA with google, or follow my messages in that mailing
> > > list)
> > > NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC, use
> > > FIFO.
> > >
> > > > thanks
> > > Regards
> > >
> > > Chris
> > > > _________________________________________________________________
> > > > Personalize your Live.com homepage with the news, weather, and photos
> you care about.
> > > > http://www.live.com/getstarted.aspx?icid=T001MSN30A0701
> > > > _______________________________________________
> > > > Linuxppc-embedded mailing list
> > > > Linuxppc-embedded@ozlabs.org
> > > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > >
> >
> >_________________________________________________________________
> >Live Search: New search found
> >http://get.live.com/search/overview
> >_______________________________________________
> >Linuxppc-embedded mailing list
> >Linuxppc-embedded@ozlabs.org
> >https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _________________________________________________________________
> ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.msn.com/cn
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE
^ permalink raw reply
* [PATCH] ucc_geth_mii: fix __exit called from __init
From: Domen Puncer @ 2007-07-20 8:19 UTC (permalink / raw)
To: leoli; +Cc: netdev, linuxppc-embedded
void __exit uec_mdio_exit(void) is called from
- static int __init ucc_geth_init(void)
- static void __exit ucc_geth_exit(void)
First one would make error path more than just an error.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
drivers/net/ucc_geth_mii.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: work-powerpc.git/drivers/net/ucc_geth_mii.c
===================================================================
--- work-powerpc.git.orig/drivers/net/ucc_geth_mii.c
+++ work-powerpc.git/drivers/net/ucc_geth_mii.c
@@ -272,7 +272,8 @@ int __init uec_mdio_init(void)
return of_register_platform_driver(&uec_mdio_driver);
}
-void __exit uec_mdio_exit(void)
+/* called from __init ucc_geth_init, therefore can not be __exit */
+void uec_mdio_exit(void)
{
of_unregister_platform_driver(&uec_mdio_driver);
}
^ permalink raw reply
* Re: Possible eHEA performance issue
From: Thomas Klein @ 2007-07-20 8:17 UTC (permalink / raw)
To: Michael Neuling
Cc: Thomas Klein, Jan-Bernd Themann, netdev, Stefan Roscher,
linux-ppc, Christoph Raisch, anton
In-Reply-To: <4634.1184900524@neuling.org>
Michael Neuling wrote:
> From ehea_start_xmit in ehea_main.c we have:
>
> if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
> spin_lock_irqsave(&pr->netif_queue, flags);
> if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
> pr->p_stats.queue_stopped++;
> netif_stop_queue(dev);
> pr->queue_stopped = 1;
> }
> spin_unlock_irqrestore(&pr->netif_queue, flags);
> }
>
> Since the conditions are the same, isn't it likely that the second 'if'
> is going to be taken. Hence, shouldn't the second 'unlikely' hint be
> removed or even changed to likely?
>
> Either way, some documentation here as to why it's done this way would
> be useful. I assume the atomic_read is cheap compared to the
> spin_unlock_irqsave, so we quickly check swqe_avail before we check it
> again properly with the lock on so we can change some stuff.
>
> Mikey
Hi Mike,
good point the second if could be a likely(). The impact isn't that big
because the if statement is true in the unlikely() case that the send queue
is full - which doesn't happen often. Anyway we will modify this in one of
the next driver versions. Thanks for the hint!
Thomas
^ permalink raw reply
* Re: [PATCH 2/2] fix showing xmon help
From: Ishizaki Kou @ 2007-07-20 8:15 UTC (permalink / raw)
To: miltonm; +Cc: paulus, linuxppc-dev
In-Reply-To: <664cbe49d76cfcba9d8a86e3a6946a2a@bga.com>
Milton Miller <miltonm@bga.com> wrote:
> On Jul 18, 2007, at 11:12 AM, Andreas Schwab wrote:
>
> > Milton Miller <miltonm@bga.com> writes:
> >
> >>> case '?':
> >>> - printf(help_string);
> >>> + xmon_puts(help_string);
> >>> break;
> >>>
> >>
> >> nonstdio.h #defines printf to xmon_printf. Please add a similar
line
> >> for puts, and use the define here. (It will avoid an unnecessary
> >> difference with the user space version).
> >
> > User space puts add a newline, which this xmon_puts doesn't.
> >
> > Andreas.
>
> Good point. This should be xmon_fputs #defined to fputs.
>
> milton
Should we change like below?
define fputs:
#define fputs(str,stream) xmon_fputs(str) /* stream is ignored. */
show the help string:
fputs(help_string, stdout);
Best regards,
Kou Ishizaki
^ permalink raw reply
* Re: [PATCH] of_detach_node()'s device node argument cannot be const
From: Segher Boessenkool @ 2007-07-20 7:57 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070720161145.2ff6860c.sfr@canb.auug.org.au>
>> ...since it modifies it (when it sets the OF_DETACHED flag).
>
> http://patchwork.ozlabs.org/linuxppc/patch?q=Stephen%
> 20Rothwell&id=12212
Ah okay :-)
Segher
^ permalink raw reply
* Re: [PATCH] [updated] PHY fixed driver: rework release path and update phy_id notation
From: Andrew Morton @ 2007-07-20 7:57 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <20070720115039.05f50f0f@localhost.localdomain>
On Fri, 20 Jul 2007 11:50:39 +0400 Vitaly Bordug <vitb@kernel.crashing.org> wrote:
> On Thu, 19 Jul 2007 23:23:37 -0700
> Andrew Morton wrote:
>
> > On Thu, 19 Jul 2007 03:38:04 +0400 Vitaly Bordug
> > <vitb@kernel.crashing.org> wrote:
> >
> > >
> > > device_bind_driver() error code returning has been fixed.
> > > release() function has been written, so that to free resources
> > > in correct way; the release path is now clean.
> > >
> > > Before the rework, it used to cause
> > > Device 'fixed@100:1' does not have a release() function, it is
> > > broken and must be fixed.
> > > BUG: at drivers/base/core.c:104 device_release()
> > >
> > > Call Trace:
> > > [<ffffffff802ec380>] kobject_cleanup+0x53/0x7e
> > > [<ffffffff802ec3ab>] kobject_release+0x0/0x9
> > > [<ffffffff802ecf3f>] kref_put+0x74/0x81
> > > [<ffffffff8035493b>] fixed_mdio_register_device+0x230/0x265
> > > [<ffffffff80564d31>] fixed_init+0x1f/0x35
> > > [<ffffffff802071a4>] init+0x147/0x2fb
> > > [<ffffffff80223b6e>] schedule_tail+0x36/0x92
> > > [<ffffffff8020a678>] child_rip+0xa/0x12
> > > [<ffffffff80311714>] acpi_ds_init_one_object+0x0/0x83
> > > [<ffffffff8020705d>] init+0x0/0x2fb
> > > [<ffffffff8020a66e>] child_rip+0x0/0x12
> > >
> > >
> > > Also changed the notation of the fixed phy definition on
> > > mdio bus to the form of <speed>+<duplex> to make it able to be used
> > > by gianfar and ucc_geth that define phy_id strictly as "%d:%d" and
> > > cleaned up the whitespace issues.
> > >
> >
> > Confused. Does the above refer to the difference between this patch
> > and the previous version, or does it just describe this patch?
> > Hopefully the latter, because the former isn't interesting, long-term.
> >
> Latter. IOW, that does mean, that mdio bus registered by this driver, now uses
> same naming conventioun that other PHYLIB things use. Hereby it will make it able to be used in
> NIC drivers other than fs_enet (and gianfar and ucc_geth are now points of interest).
>
> > If is _is_ a full standalone description of this patch then it's a
> > bit hard to follow ;)
> >
> Hmm -so what are my options - change the description and resubmit?
umm, I guess it's OK as-is. But it wasn't clear to me which sort of
changelog it was.
> > > +config FIXED_MII_1000_FDX
> > > + bool "Emulation for 1000M Fdx fixed PHY behavior"
> > > + depends on FIXED_PHY
> > > +
> > > +config FIXED_MII_AMNT
> > > + int "Number of emulated PHYs to allocate "
> > > + depends on FIXED_PHY
> > > + default "1"
> > > + ---help---
> > > + Sometimes it is required to have several independent
> > > emulated
> > > + PHYs on the bus (in case of multi-eth but phy-less HW for
> > > instance).
> > > + This control will have specified number allocated for each
> > > fixed
> > > + PHY type enabled.
> >
> > Shouldn't these be runtime options (ie: module parameters)?
> >
> I thought about it but this thing is more like the one that will never tend/required to change while\
> configured.. Will add if you see it appropriate though.
99% of users don't compile their own kernels: their vendor will have to
make this decision for them, and it sounds like any decision which they
make will be wrong for some of their users?
^ permalink raw reply
* Re: [PATCH] [updated] PHY fixed driver: rework release path and update phy_id notation
From: Vitaly Bordug @ 2007-07-20 7:50 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <20070719232337.184942e0.akpm@linux-foundation.org>
On Thu, 19 Jul 2007 23:23:37 -0700
Andrew Morton wrote:
> On Thu, 19 Jul 2007 03:38:04 +0400 Vitaly Bordug
> <vitb@kernel.crashing.org> wrote:
>
> >
> > device_bind_driver() error code returning has been fixed.
> > release() function has been written, so that to free resources
> > in correct way; the release path is now clean.
> >
> > Before the rework, it used to cause
> > Device 'fixed@100:1' does not have a release() function, it is
> > broken and must be fixed.
> > BUG: at drivers/base/core.c:104 device_release()
> >
> > Call Trace:
> > [<ffffffff802ec380>] kobject_cleanup+0x53/0x7e
> > [<ffffffff802ec3ab>] kobject_release+0x0/0x9
> > [<ffffffff802ecf3f>] kref_put+0x74/0x81
> > [<ffffffff8035493b>] fixed_mdio_register_device+0x230/0x265
> > [<ffffffff80564d31>] fixed_init+0x1f/0x35
> > [<ffffffff802071a4>] init+0x147/0x2fb
> > [<ffffffff80223b6e>] schedule_tail+0x36/0x92
> > [<ffffffff8020a678>] child_rip+0xa/0x12
> > [<ffffffff80311714>] acpi_ds_init_one_object+0x0/0x83
> > [<ffffffff8020705d>] init+0x0/0x2fb
> > [<ffffffff8020a66e>] child_rip+0x0/0x12
> >
> >
> > Also changed the notation of the fixed phy definition on
> > mdio bus to the form of <speed>+<duplex> to make it able to be used
> > by gianfar and ucc_geth that define phy_id strictly as "%d:%d" and
> > cleaned up the whitespace issues.
> >
>
> Confused. Does the above refer to the difference between this patch
> and the previous version, or does it just describe this patch?
> Hopefully the latter, because the former isn't interesting, long-term.
>
Latter. IOW, that does mean, that mdio bus registered by this driver, now uses
same naming conventioun that other PHYLIB things use. Hereby it will make it able to be used in
NIC drivers other than fs_enet (and gianfar and ucc_geth are now points of interest).
> If is _is_ a full standalone description of this patch then it's a
> bit hard to follow ;)
>
Hmm -so what are my options - change the description and resubmit?
> > +config FIXED_MII_1000_FDX
> > + bool "Emulation for 1000M Fdx fixed PHY behavior"
> > + depends on FIXED_PHY
> > +
> > +config FIXED_MII_AMNT
> > + int "Number of emulated PHYs to allocate "
> > + depends on FIXED_PHY
> > + default "1"
> > + ---help---
> > + Sometimes it is required to have several independent
> > emulated
> > + PHYs on the bus (in case of multi-eth but phy-less HW for
> > instance).
> > + This control will have specified number allocated for each
> > fixed
> > + PHY type enabled.
>
> Shouldn't these be runtime options (ie: module parameters)?
>
I thought about it but this thing is more like the one that will never tend/required to change while\
configured.. Will add if you see it appropriate though.
> >
> > ...
> >
> > + * Private information hoder for mii_bus
>
> tpyo.
ok
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH] Treat ISI faults as read faults on classic 32-bit PowerPC
From: Segher Boessenkool @ 2007-07-20 7:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Johannes Berg
In-Reply-To: <18079.63067.248965.356540@cargo.ozlabs.ibm.com>
>> Should you really be testing VM_READ|VM_WRITE, or should it just
>> be VM_READ?
>
> We test VM_READ | VM_WRITE | VM_EXEC in the read case below, and that
> is because we have no HPTE encoding to say "writable but not readable"
> or "executable but not readable". Similarly we have no encoding to
> say "writable but not executable" on classic processors, so if you
> have just VM_WRITE set, you get a page that is readable, writable and
> executable.
Ah yes. I thought "executable requires readable", but
that is with the CPU its flags, not the Linux flags.
Would it be a good idea to map Linux flags to CPU flags
somewhere early in this function? It might simplify some
code, and things certainly would become more readable.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-20 7:26 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707191932300.3365@poirot.grange>
>> You might want to put vendor names in the "compatible"
>> entries, dunno though, maybe these are "cross-vendor"
>> ICs?
>
> You mean like
>
> compatible = "ricoh,rs5c372a"
Yeah, like that. I'm not sure it is needed for these,
but it won't hurt either.
> + strncpy(info->driver_name, i2c_devices[i].i2c_driver,
> KOBJ_NAME_LEN);
> + strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
Why not just strcpy(), btw?
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || len < sizeof(int) || *addr > 0xffff)
> + continue;
Give a warning when the addr won't fit in 16 bits?
Segher
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Segher Boessenkool @ 2007-07-20 7:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <1184881198.25235.347.camel@localhost.localdomain>
>> So your plan is to prefer the device tree over the cputable, and
>> maybe even deprecate the cputable?
>
> Nah, you are fine not putting anything, but if it's in the DT it
> should
> be correct, not "0". Else, just don't put it in the DT.
Ah okay. So we should recommend to not put any of those
properties into DTS files at all? If so, I'll create a
patch to remove them.
> We use the DT to override cputable but that's mostly useful for things
> like pSeries where you can get some processors in "compatibility" mode
> over another one, or some virtual PVRs, and other fancy things like
> that
> where the cputable isn't very useful.
Yeah, and it's a good idea to have the device tree override
the cputable always, with real OF, anyway. (Well there are
buggy device trees out there, of course ;-) )
Segher
^ permalink raw reply
* Re: [PATCH] [updated] PHY fixed driver: rework release path and update phy_id notation
From: Andrew Morton @ 2007-07-20 6:23 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev, linux-kernel, Jeff Garzik, netdev
In-Reply-To: <20070718233804.24451.22543.stgit@localhost.localdomain>
On Thu, 19 Jul 2007 03:38:04 +0400 Vitaly Bordug <vitb@kernel.crashing.org> wrote:
>
> device_bind_driver() error code returning has been fixed.
> release() function has been written, so that to free resources
> in correct way; the release path is now clean.
>
> Before the rework, it used to cause
> Device 'fixed@100:1' does not have a release() function, it is broken
> and must be fixed.
> BUG: at drivers/base/core.c:104 device_release()
>
> Call Trace:
> [<ffffffff802ec380>] kobject_cleanup+0x53/0x7e
> [<ffffffff802ec3ab>] kobject_release+0x0/0x9
> [<ffffffff802ecf3f>] kref_put+0x74/0x81
> [<ffffffff8035493b>] fixed_mdio_register_device+0x230/0x265
> [<ffffffff80564d31>] fixed_init+0x1f/0x35
> [<ffffffff802071a4>] init+0x147/0x2fb
> [<ffffffff80223b6e>] schedule_tail+0x36/0x92
> [<ffffffff8020a678>] child_rip+0xa/0x12
> [<ffffffff80311714>] acpi_ds_init_one_object+0x0/0x83
> [<ffffffff8020705d>] init+0x0/0x2fb
> [<ffffffff8020a66e>] child_rip+0x0/0x12
>
>
> Also changed the notation of the fixed phy definition on
> mdio bus to the form of <speed>+<duplex> to make it able to be used by
> gianfar and ucc_geth that define phy_id strictly as "%d:%d" and cleaned up
> the whitespace issues.
>
Confused. Does the above refer to the difference between this patch and
the previous version, or does it just describe this patch? Hopefully the
latter, because the former isn't interesting, long-term.
If is _is_ a full standalone description of this patch then it's a bit hard
to follow ;)
> +config FIXED_MII_1000_FDX
> + bool "Emulation for 1000M Fdx fixed PHY behavior"
> + depends on FIXED_PHY
> +
> +config FIXED_MII_AMNT
> + int "Number of emulated PHYs to allocate "
> + depends on FIXED_PHY
> + default "1"
> + ---help---
> + Sometimes it is required to have several independent emulated
> + PHYs on the bus (in case of multi-eth but phy-less HW for instance).
> + This control will have specified number allocated for each fixed
> + PHY type enabled.
Shouldn't these be runtime options (ie: module parameters)?
>
> ...
>
> + * Private information hoder for mii_bus
tpyo.
^ permalink raw reply
* Re: [PATCH] of_detach_node()'s device node argument cannot be const
From: Stephen Rothwell @ 2007-07-20 6:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <11849111183072-git-send-email-segher@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 343 bytes --]
On Fri, 20 Jul 2007 07:58:38 +0200 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> ...since it modifies it (when it sets the OF_DETACHED flag).
http://patchwork.ozlabs.org/linuxppc/patch?q=Stephen%20Rothwell&id=12212
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Please pull Open Firmware consolidation patches
From: Stephen Rothwell @ 2007-07-20 6:00 UTC (permalink / raw)
To: Linus; +Cc: LKML, wli, ppc-dev, paulus, sparclinux, David S. Miller
[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]
Hi Linus,
Please pull the Open Firmware device tree consolidation patches from the
master branch of
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/ofcons.git master
The intention here is that there should be no behavioural changes and
minimal code changes (apart from movement of the code to common places).
There are, however a couple of unavoidable changes:
- some of the accessor functions now take a read lock on Sparc[64]
where they didn't before.
- the bus structures are initialised at runtime.
These changes have been reviewed on the PowerPC and Sparc Linux mailing
lists and acked by both maintainers (Dave Miller and Paul Mackerras).
Kernels with tese changes have been built and booted on a SunBlade1500
(thanks Dave), a Power5+ pSeries machine and a small iSeries machine.
Dave is rather keen for these to go in ("Did you send him a pull request
yet? Sorry, I'm quite anxious :)").
Stephen Rothwell (12):
Split out common parts of prom.h
Start split out of common open firmware code
Consolidate of_device_is_compatible
Consolidate of_find_property
Consolidate of_get_parent
Consolidate of_get_next_child
Consolidate of_find_node_by routines
Begin to consolidate of_device.c
Begin consolidation of of_device.h
[SPARC/64] Rename some functions like PowerPC
Create linux/of_platorm.h
Create drivers/of/platform.c
arch/powerpc/Kconfig | 3 +
arch/powerpc/kernel/of_device.c | 122 +----------------
arch/powerpc/kernel/of_platform.c | 82 +-----------
arch/powerpc/kernel/prom.c | 250 +---------------------------------
arch/sparc/Kconfig | 3 +
arch/sparc/kernel/of_device.c | 222 ++----------------------------
arch/sparc/kernel/prom.c | 173 +-----------------------
arch/sparc/kernel/time.c | 2 +-
arch/sparc64/Kconfig | 3 +
arch/sparc64/kernel/auxio.c | 2 +-
arch/sparc64/kernel/of_device.c | 238 +++-----------------------------
arch/sparc64/kernel/power.c | 2 +-
arch/sparc64/kernel/prom.c | 173 +-----------------------
arch/sparc64/kernel/time.c | 2 +-
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/of/Kconfig | 3 +
drivers/of/Makefile | 2 +
drivers/of/base.c | 275 +++++++++++++++++++++++++++++++++++++
drivers/of/device.c | 131 ++++++++++++++++++
drivers/of/platform.c | 96 +++++++++++++
include/asm-powerpc/of_device.h | 22 +---
include/asm-powerpc/of_platform.h | 38 +-----
include/asm-powerpc/prom.h | 50 ++-----
include/asm-sparc/of_device.h | 49 +------
include/asm-sparc/of_platform.h | 32 +++++
include/asm-sparc/prom.h | 62 +++------
include/asm-sparc64/of_device.h | 50 +------
include/asm-sparc64/of_platform.h | 33 +++++
include/asm-sparc64/prom.h | 62 +++------
include/linux/of.h | 61 ++++++++
include/linux/of_device.h | 26 ++++
include/linux/of_platform.h | 57 ++++++++
33 files changed, 846 insertions(+), 1483 deletions(-)
create mode 100644 drivers/of/Kconfig
create mode 100644 drivers/of/Makefile
create mode 100644 drivers/of/base.c
create mode 100644 drivers/of/device.c
create mode 100644 drivers/of/platform.c
create mode 100644 include/asm-sparc/of_platform.h
create mode 100644 include/asm-sparc64/of_platform.h
create mode 100644 include/linux/of.h
create mode 100644 include/linux/of_device.h
create mode 100644 include/linux/of_platform.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] of_detach_node()'s device node argument cannot be const
From: Segher Boessenkool @ 2007-07-20 5:58 UTC (permalink / raw)
To: linuxppc-dev
...since it modifies it (when it sets the OF_DETACHED flag).
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
---
arch/powerpc/kernel/prom.c | 2 +-
include/asm-powerpc/prom.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 37ff99b..67a1bda 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -1433,7 +1433,7 @@ void of_attach_node(struct device_node *np)
* a reference to the node. The memory associated with the node
* is not freed until its refcount goes to zero.
*/
-void of_detach_node(const struct device_node *np)
+void of_detach_node(struct device_node *np)
{
struct device_node *parent;
diff --git a/include/asm-powerpc/prom.h b/include/asm-powerpc/prom.h
index 1632baa..1bba741 100644
--- a/include/asm-powerpc/prom.h
+++ b/include/asm-powerpc/prom.h
@@ -160,7 +160,7 @@ extern unsigned long __init of_get_flat_dt_root(void);
/* For updating the device tree at runtime */
extern void of_attach_node(struct device_node *);
-extern void of_detach_node(const struct device_node *);
+extern void of_detach_node(struct device_node *);
/* Other Prototypes */
extern void finish_device_tree(void);
--
1.5.2.1.144.gabc40-dirty
^ permalink raw reply related
* Re: [PATCH 12/12] Create drivers/of/platform.c
From: David Miller @ 2007-07-20 4:20 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070720012032.ad4419a1.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jul 2007 01:20:32 +1000
> and populate it with the common parts from PowerPC and Sparc[64].
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
All tested on SunBlade1500.
Please push this to Linus Stephen, thanks!
^ permalink raw reply
* Re: [PATCH 11/12] Create linux/of_platorm.h
From: David Miller @ 2007-07-20 4:01 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070720011925.f51f998a.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jul 2007 01:19:25 +1000
> Move common stuff from asm-powerpc/of_platform.h to here and
> move the common bits from asm-sparc*/of_device.h here as well.
>
> Create asm-sparc*/of_platform.h and move appropriate parts of
> of_device.h to them.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
Tested on SunBlade1500.
^ permalink raw reply
* Re: [PATCH 09/12] Begin consolidation of of_device.h
From: David Miller @ 2007-07-20 3:33 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070720011708.7919947c.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jul 2007 01:17:08 +1000
> This just moves the common stuff from the arch of_device.h files to
> linux/of_device.h.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
Tested on SunBlade1500.
^ permalink raw reply
* Re: [PATCH 08/12] Begin to consolidate of_device.c
From: David Miller @ 2007-07-20 3:21 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070720011612.cc101b92.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jul 2007 01:16:12 +1000
> This moves all the common parts for the Sparc, Sparc64 and PowerPC
> of_device.c files into drivers/of/device.c.
>
> Apart from the simple move, Sparc gains of_match_node() and a call to
> of_node_put in of_release_dev(). PowerPC gains better recovery if
> device_create_file() fails in of_device_register().
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
Tested on SunBlade1500.
^ permalink raw reply
* Re: [PATCH 07/12] Consolidate of_find_node_by routines
From: David Miller @ 2007-07-20 3:12 UTC (permalink / raw)
To: sfr; +Cc: sparclinux, linuxppc-dev, paulus, wli
In-Reply-To: <20070720011450.d0b97300.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 20 Jul 2007 01:14:50 +1000
> This consolidates the routines of_find_node_by_path, of_find_node_by_name,
> of_find_node_by_type and of_find_compatible_device. Again, the comparison
> of strings are done differently by Sparc and PowerPC and also these add
> read_locks around the iterations.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
Tested on SunBlade1500.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox