Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch

On Thu, Jun 17, 2010 at 11:56:53AM +1000, Michael Neuling wrote: > > > In message <20100616004839.ga18...@linux.vnet.ibm.com> you wrote: > > crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64 > > and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP. > > Fix

Re: Porting a driver to powerpc using FDT

> We have only done a text search/replace lite5200 to jkc5200. I meant to write: We copied lite5200.c to jkc5200n8.c, and have only done a text search/replace lite5200 to jkc5200n8 Chris ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org ht

Re: Porting a driver to powerpc using FDT

dsa_of_init is successfully called; but dsa_of_probe is not called. >>> >>> That means the node is not being used to register an of_device. I >>> need some more information to suggest how best to fix this. >> >>> What SoC are you using? >>> What file in arch/powerpc/platforms/* is used t

Re: [PATCH RFC] ppc: fix default_machine_crash_shutdown #ifdef botch

In message <20100616004839.ga18...@linux.vnet.ibm.com> you wrote: > crash_kexec_wait_realmode() is defined only if CONFIG_PPC_STD_MMU_64 > and CONFIG_SMP, but is called if CONFIG_PPC_STD_MMU_64 even if !CONFIG_SMP. > Fix the conditional compilation around the invocation. > > Untested, probably d

Re: [PATCH] gianfar: Fix oversized packets handling

From: Anton Vorontsov Date: Sat, 12 Jun 2010 00:51:03 +0400 > Issuing the following command on host: > > $ ifconfig eth2 mtu 1600 ; ping 10.0.0.27 -s 1485 -c 1 > > Makes some boards (tested with MPC8315 rev 1.1 and MPC8313 rev 1.0) > oops like this: ... > Dumped buffer descriptors showed that

Re: [PATCH 2/2] ehea: Fix kernel deadlock in DLPAR-mem processing

From: "Jan-Bernd Themann" Date: Tue, 15 Jun 2010 17:35:42 +0200 > Port reset operations and memory add/remove operations need to > be serialized to avoid a kernel deadlock. The deadlock is caused > by calling the napi_disable() function twice. > Therefore we have to employ the dlpar_mem_lock in

Re: [PATCH 1/2] ehea: fix delayed packet processing

From: Jay Vosburgh Date: Tue, 15 Jun 2010 09:45:47 -0700 > Jan-Bernd Themann wrote: > >>In the eHEA poll function an rmb() is required. Without that some packets >>on the receive queue are not seen and thus delayed until the next interrupt >>is handled for the same receive queue. >> >>Signed-of

Re: [PATCH 04/12] phylib: add a way to make PHY time stamps possible.

From: Richard Cochran Date: Tue, 15 Jun 2010 18:08:20 +0200 > +static inline void skb_tx_timetamp(struct phy_device *phy, struct sk_buff > *skb) > +{ > + union skb_shared_tx *shtx = skb_tx(skb); > + > + if (shtx->hardware && phy && phy->drv->txtstamp) > + phy->drv->txtstamp(p

Re: Porting a driver to powerpc using FDT

On Wed, Jun 16, 2010 at 4:48 PM, Chris Alfred wrote: >>> dsa_of_init is successfully called; but dsa_of_probe is not called. >> >> That means the node is not being used to register an of_device.  I >> need some more information to suggest how best to fix this. > >> What SoC are you using? >> What

Re: Porting a driver to powerpc using FDT

>> dsa_of_init is successfully called; but dsa_of_probe is not called. > > That means the node is not being used to register an of_device. I > need some more information to suggest how best to fix this. > What SoC are you using? > What file in arch/powerpc/platforms/* is used to setup your machin

Re: Porting a driver to powerpc using FDT

On Wed, Jun 16, 2010 at 4:06 PM, Chris Alfred wrote: > Grant Likely wrote: >> On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred >> wrote: >>> I am trying to port a DSA (Distributed Switch Architecture) driver >>> for the Micrel KS8995M managed switch connected to a MPC5200. There >>> is an SPI interf

Re: Porting a driver to powerpc using FDT

Grant Likely wrote: > On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred > wrote: >> I am trying to port a DSA (Distributed Switch Architecture) driver >> for the Micrel KS8995M managed switch connected to a MPC5200. There >> is an SPI interface and MII interface managed by the DSA driver. >> >> I can'

Re: [PATCH] gianfar: Fix setup of RX time stamping

From: Anton Vorontsov Date: Fri, 11 Jun 2010 16:20:23 +0400 > On Fri, Jun 11, 2010 at 01:49:05PM +0200, Manfred Rudigier wrote: >> Previously the RCTRL_TS_ENABLE bit was set unconditionally. However, if >> the RCTRL_TS_ENABLE is set without TMR_CTRL[TE], the driver does not work >> properly on so

Re: Request review of device tree documentation

On 06/16/2010 07:39 AM, Nicolas Pitre wrote: > The cost function _is_ different for the Linux community and decision > makers at chip vendor companies. I know that for having worked long > enough at a prominent chip vendor already. > > Those vendors want to ship a product and be first on the mar

Re: [PATCH 2/2] of: kill struct of_device

From: Grant Likely Date: Fri, 04 Jun 2010 15:11:38 -0600 > Now that the device tree node pointer has been moved out of struct > of_device and into the common struct device, there isn't anything > unique about of_device anymore. In fact, there isn't much need > for a separate of_bus when all buss

RE: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support

> -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 Grant Likely > Sent: Wednesday, June 16, 2010 1:02 PM > To: Sergey Temerkhanov > Cc: linuxppc-dev@lists.oz

Re: [PATCHv3] [RFC] Xilinx Virtex 4 FX Soft FPU support

On Wed, May 26, 2010 at 11:04 AM, Sergey Temerkhanov wrote: > This patch enables support for Xilinx Virtex 4 FX singe-float FPU. > > Changelog v2-v3: >        -Fixed whitespaces for SAVE_FPR/REST_FPR. >        -Changed description of MSR_AP bit. >        -Removed the stub for APU unavailable excep

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

On Wed, 16 Jun 2010 11:26:39 -0500 Timur Tabi wrote: > Anatolij Gustschin wrote: > > On Wed, 16 Jun 2010 10:42:28 -0500 > > Timur Tabi wrote: > > > >> Anatolij Gustschin wrote: > >> > >>> Any chance this could be done soon? I'd like to include the > >>> MPC5121e DIU support in 2.6.36 since it i

Re: [Patch v2 1/2] 5200/mpc: improve i2c bus error recovery

Am 19.05.10 18:02 schrieb(en) Grant Likely: > That's , isn't it? >  Hmmm, didn't find it there... :-/ Ugh... Stupid typing too fast. I meant to say, "I *don't* think ben has asked me to take..." Well this leaves a bit of a mess. I'll make

Re: [PATCH v2] lite5200: fix ethernet phy address

On Tue, Jun 15, 2010 at 4:19 PM, Dmitry Eremin-Solenikov wrote: > Dmitry Eremin-Solenikov wrote: > >> According to my schematics, on Lite5200 board ethernet phy uses address >> 0 (all ADDR lines are pulled down). With this change I can talk to >> onboard phy (LXT971) and correctly use autonegotiat

Re: Porting a driver to powerpc using FDT

On Tue, Jun 15, 2010 at 4:19 PM, Chris Alfred wrote: > I am trying to port a DSA (Distributed Switch Architecture) driver for > the Micrel KS8995M managed switch connected to a MPC5200. There is an > SPI interface and MII interface managed by the DSA driver. > > I can't understand how probe gets c

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

> Can you email me, perhaps in one tarball, all of the patches I need? Or push a git tree :) -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

Anatolij Gustschin wrote: > On Wed, 16 Jun 2010 10:42:28 -0500 > Timur Tabi wrote: > >> Anatolij Gustschin wrote: >> >>> Any chance this could be done soon? I'd like to include the >>> MPC5121e DIU support in 2.6.36 since it is currently broken in >>> mainline and the patches provide the fix. >>

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

On Wed, 16 Jun 2010 10:42:28 -0500 Timur Tabi wrote: > Anatolij Gustschin wrote: > > > Any chance this could be done soon? I'd like to include the > > MPC5121e DIU support in 2.6.36 since it is currently broken in > > mainline and the patches provide the fix. > > Ok, I'll try it today. Thanks!

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

Anatolij Gustschin wrote: > Any chance this could be done soon? I'd like to include the MPC5121e DIU > support in 2.6.36 since it is currently broken in mainline and the patches > provide the fix. Ok, I'll try it today. ___ Linuxppc-dev mailing list Li

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Micha Nelissen wrote: Do you mean like attached? I had to change the order of the '_GLOBAL' definitions __setup_cpu_e500v1/__setup_cpu_e500v2 since this bit is e500v2 only. Hmm, maybe need to use r0 or r3 instead of r2? Micha Index: linux/arch/powerpc/kernel/cpu_setup_fsl_booke.S

[PATCH] powerpc/iseries: fix possible null pointer dereference in iSeries_pcibios_fixup_resources

I don't know if this is a right fix for the problem since of_get_property can return NULL. Since iseries_device_information is used only for informational purpose, we can skip this function without valid HvSubBusNumber number. Signed-off-by: Denis Kirjanov --- arch/powerpc/platforms/iseries/pci.c

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Kumar Gala wrote: +BEGIN_MMU_FTR_SECTION + mfspr r2,SPRN_HID0 + ori r2,r2,hid0_en_mas7_upd...@l + mtspr SPRN_HID0, r2 +END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS) +#endif If you want to do this, do it in: arch/powerpc/kernel/cpu_setup_fsl_booke.S Do you mean like at

Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.

On Wed, Jun 16, 2010 at 4:05 AM, Richard Cochran wrote: > On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote: >> Won't this break things for existing DP83640 users? > > Nope, the driver was only added five patches ago, and it only offers > the timestamping stuff. The standard PHY functio

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

On Jun 16, 2010, at 1:58 AM, Micha Nelissen wrote: > Hi, > > Attached is a patch to fix large physical address support for the e500v2 > core. When >4GB addresses are used, the MAS7 register needs to be valid for > tlbsx instruction usage. > > Please review and apply. > > Micha > diff -u -ru

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Timur Tabi wrote: I'm sorry, but Linux does depend on the boot loader, and U-Boot does need to know whether Linux is going to use 36-bit addressing. Why? That's just the way it works. What a great design philosophy! Linux patches that repeat what U-Boot already does just so that you do

Re: Request review of device tree documentation

On Wed, 16 Jun 2010, Mike Rapoport wrote: > Mitch Bradley wrote: > > One counterargument, of course, is that "there is a better way". But it is > > only "better" under a cost function that values things differently than the > > vendors value them. Were that not so, the vendors would gladly use th

[PATCH] powerpc/iseries: fix constant warning

Fix smatch warning: constant 0x8000 is so big it is unsigned long Signed-off-by: Denis Kirjanov --- arch/powerpc/include/asm/abs_addr.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/include/asm/abs_addr.h b/arch/powerpc/include/asm/abs_addr.h

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

On Wed, Jun 16, 2010 at 4:24 AM, Micha Nelissen wrote: > IMHO: > 1) Linux should not be dependent on U-boot or any other bootloader, or at > least as possible > 2) U-boot cannot (and does not want to) know whether Linux is going to use > large physical addresses. To quote The Dude: "Yeah, well,

Re: [PATCH 08/12] ptp: Added a brand new class driver for ptp clocks.

On Tue, Jun 15, 2010 at 11:00:10AM -0600, Grant Likely wrote: > > Question from an ignorant reviewer: Why a new interface instead of > working with the existing high resolution timers infrastructure? Short answer: Timers are only one part of the PTP API. If you offer the PTP clock as a Linux clo

Re: Request review of device tree documentation

On 16 Jun 2010, at 12:41, Jamie Lokier wrote: > Mike Rapoport wrote: >>> Which of course raises the question: How does the Linux community view >>> such SoC vendors? Are they embraced and eagerly supported, or (either >>> openly or secretly) viewed as a nuisance? How does the widespread >>> o

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

> -Original Message- > From: Micha Nelissen [mailto:mi...@neli.hopto.org] > Sent: Wednesday, June 16, 2010 5:04 PM > To: Aggrwal Poonam-B10812 > Cc: linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] > > Aggrwal Poonam-B10812 wrote: > >

Re: Request review of device tree documentation

Mike Rapoport wrote: > >Which of course raises the question: How does the Linux community view > >such SoC vendors? Are they embraced and eagerly supported, or (either > >openly or secretly) viewed as a nuisance? How does the widespread > >objection to something that such vendors "would make

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Aggrwal Poonam-B10812 wrote: Not sure of other platforms but on 85xx platforms on which I am currently working u-boot does LAW and eLBC programming for 36bit physical address. Hence possibly u-boot has to made aware of large physical address space. Please correct me if I am wrong. Yes, I can

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

> -Original Message- > From: Micha Nelissen [mailto:mi...@neli.hopto.org] > Sent: Wednesday, June 16, 2010 2:55 PM > To: Aggrwal Poonam-B10812; linuxppc-dev@lists.ozlabs.org > Subject: Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE] > > Aggrwal Poonam-B10812 wrote: > >> Att

Re: Request review of device tree documentation

Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread

Re: Request review of device tree documentation

Mitch Bradley wrote: I'm also objecting the step (b) and, fortunately, it's not yet the status quo. Current U-Boot/kernel implementations I've encountered still do not have OS calls to resident HW access routines. But if such calls would be allowed, my impression is that SoC vendors would m

[PATCH 2.6.35 v3] powerpc: fix logic error in fixup_irqs

When SPARSE_IRQ is set, irq_to_desc() can return NULL. While the code here has a check for NULL, it's not really correct. Fix it by separating the check for it. This fixes CPU hot unplug for me. Reported-by: Alastair Bridgewater Cc: sta...@kernel.org [2.6.32+] Signed-off-by: Johannes Berg --- v

Re: [PATCH 12/12] ptp: Added a clock driver for the National Semiconductor PHYTER.

On Tue, Jun 15, 2010 at 12:49:13PM -0600, Grant Likely wrote: > Won't this break things for existing DP83640 users? Nope, the driver was only added five patches ago, and it only offers the timestamping stuff. The standard PHY functions just call the generic functions, so the PHY works fine even wi

Re: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Aggrwal Poonam-B10812 wrote: Attached is a patch to fix large physical address support for the This is already being done by u-boot, should linux set it again? Yikes! Took me 5 min to reformat your email. Our version of U-boot does not but it's not latest greatest. IMHO: 1) Linux should not

RE: [PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

> -Original Message- > From: linuxppc-dev-bounces+poonam.aggrwal=freescale@lists.ozlabs.org > [mailto:linuxppc-dev- > bounces+poonam.aggrwal=freescale@lists.ozlabs.org] On Behalf Of Micha > Nelissen > Sent: Wednesday, June 16, 2010 12:29 PM > To: linuxppc-dev@lists.ozlabs.org > Su

Re: Request review of device tree documentation

Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: Mike Rapoport wrote: Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and t

Re: [PATCH 0/5] Rework MPC5121 DIU support (for 2.6.35)

Hi Timur, On Fri, 4 Jun 2010 10:46:28 -0500 Timur Tabi wrote: > On Tue, Jun 1, 2010 at 4:38 AM, Anatolij Gustschin wrote: > > > Could you please test these patches on MPC8610 HPCD? I think these > > changes won't break that platform. The patches apply cleanly on > > 2.6.35-rc1. > > I'll try t

[PATCH] e500v2 36 bit large physical HID0[EN_MAS7_UPDATE]

Hi, Attached is a patch to fix large physical address support for the e500v2 core. When >4GB addresses are used, the MAS7 register needs to be valid for tlbsx instruction usage. Please review and apply. Micha diff -u -ru linux-2.6.34/arch/powerpc/include/asm/reg.h linux-2.6.34-fix/arch/powe

Re: Request review of device tree documentation

In message: <4c187013.5000...@firmworks.com> Mitch Bradley writes: : Mike Rapoport wrote: : > Mitch Bradley wrote: : >> Mike Rapoport wrote: : >>> Mitch Bradley wrote: : >>> : The second topic is the hypothetical use of OFW as a HAL. That will : not happen for several reasons

Re: Request review of device tree documentation

Mitch Bradley wrote: The second topic is the hypothetical use of OFW as a HAL. That will not happen for several reasons. The opposition to the idea is widespread and deeply held, and there are good arguments to support that opposition. Furthermore, the economic conditions necessary for the