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: [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: [PATCH 1/2] sparc/of: Move of_device fields into struct pdev_archdata

From: Grant Likely Date: Fri, 04 Jun 2010 15:11:33 -0600 > This patch moves SPARC architecture specific data members out of > struct of_device and into the pdev_archdata structure. The reason > for this change is to unify the struct of_device definition amongst > all the architectures. It also

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: 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 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. ___ devicetree-discuss mailing l

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: 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

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

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 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: 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

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