Re: [PATCH v2 0/3] extend stmmac DT support
From: Srinivas KANDAGATLA Date: Thu, 4 Jul 2013 10:34:56 +0100 > Thankyou for the comments on v1 patches. > > This patch series adds support to new gmac versions 3.6.10 and 3.710, these > versions of IP are integrated into ST STiH415/STiH416 SOCs. > This patchset also adds phy reset capablity to stmmac-mdio driver via DT. > > Changes since v1: > - Fixed unused variable warings pointed by Dave M. > > Changes since RFC: > - re-use existing compatible strings to select right properties. > - clean up reset callback support so that DT is not parsed everytime. Series applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v1 0/3] extend stmmac DT support.
From: Srinivas KANDAGATLA Date: Tue, 2 Jul 2013 14:03:39 +0100 > From: Srinivas Kandagatla > > Hi Peppe, > > Thankyou for the comments on RFC patches. > > This patch series adds support to new gmac versions 3.6.10 and 3.710, these > versions of IP are integrated into ST STiH415/STiH416 SOCs. > This patchset also adds phy reset capablity to stmmac-mdio driver via DT. > > Changes since RFC: > - re-use existing compatible strings to select right properties. > - clean up reset callback support so that DT is not parsed everytime. You are going to have to fix up the following build warnings and resubmit: CC [M] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.o drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function ‘stmmac_mdio_reset’: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:137:17: warning: unused variable ‘dev’ [-Wunused-variable] drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c: In function ‘stmmac_mdio_register’: drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c:200:17: warning: unused variable ‘dev’ [-Wunused-variable] Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] net: ethernet: davinci_emac: remove redundant dev_err call in davinci_emac_probe()
From: Mugunthan V N Date: Tue, 2 Jul 2013 10:50:11 +0530 > On Tuesday 02 July 2013 06:27 AM, Wei Yongjun wrote: >> From: Wei Yongjun >> >> There is a error message within devm_ioremap_resource >> already, so remove the dev_err call to avoid redundant >> error message. >> >> Signed-off-by: Wei Yongjun > > Acked-by: Mugunthan V N Applied, thanks everyone. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arc_emac: fix compile-time errors & warnings on PPC64
From: Alexey Brodkin Date: Wed, 26 Jun 2013 11:49:26 +0400 > As reported by "kbuild test robot" there were some errors and warnings > on attempt to build kernel with "make ARCH=powerpc allmodconfig". > > And this patch addresses both errors and warnings. > Below is a list of introduced changes: > 1. Fix compile-time errors (misspellings in "dma_unmap_single") on PPC. > 2. Use DMA address instead of "skb->data" as a pointer to data buffer. > This fixed warnings on pointer to int conversion on 64-bit systems. > 3. Re-implemented initial allocation of Rx buffers in "arc_emac_open" in > the same way they're re-allocated during operation (receiving packets). > So once again DMA address could be used instead of "skb->data". > 4. Explicitly use EMAC_BUFFER_SIZE for Rx buffers allocation. > > Signed-off-by: Alexey Brodkin Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v8] ethernet/arc/arc_emac - Add new driver
From: Alexey Brodkin Date: Mon, 24 Jun 2013 09:54:27 +0400 > Driver for non-standard on-chip ethernet device ARC EMAC 10/100, > instantiated in some legacy ARC (Synopsys) FPGA Boards such as > ARCAngel4/ML50x. > > Signed-off-by: Alexey Brodkin Applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7] ethernet/arc/arc_emac - Add new driver
From: Joe Perches Date: Fri, 21 Jun 2013 07:43:33 -0700 > Maybe add a Kconfig "depends on !64BIT". Please, no. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] ethernet/arc/arc_emac - Add new driver
From: Joe Perches
Date: Thu, 13 Jun 2013 11:33:21 -0700
> On Thu, 2013-06-13 at 21:25 +0300, Andy Shevchenko wrote:
>> On Thu, Jun 13, 2013 at 5:37 PM, Alexey Brodkin
>> > + if (unlikely((info & OWN_MASK) == FOR_EMAC)) {
>> > + /* BD is still owned by EMAC */
>> > + continue;
>> > + }
>>
>> Redundant braces.
>
> Maybe not. Braces can be a visual aid when there is
> a comment in the test.
Agreed.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
From: Linus Walleij Date: Mon, 10 Jun 2013 17:48:16 +0200 > On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N wrote: > >>> If you want to merge the direct networking parts of this series into >>> another tree, I'm fine with that: >>> >>> Acked-by: David S. Miller >> >> David >> >> Can you the below patch series as i have adopted pinctrl PM api in another >> series, >> this patch has direct usage of pinctrl_select_state apis >> http://marc.info/?l=linux-netdev&m=137054250018667&w=2 >> >> Linus Walleij >> >> Please drop this patch series and take my other [atch set mentioned above >> with David's Ack. > > Sure I didn't see David ACK the new versions explicitly but > since they're even less intrusive I'll apply them assuming > his ACK on these versions too... Just in case it isn't clear: Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Fix locking vs. interrupts
From: Grant Likely Date: Wed, 12 Jun 2013 10:06:12 +0100 > On Wed, 12 Jun 2013 10:25:56 +0200 (CEST), Thomas Gleixner > wrote: >> On Wed, 12 Jun 2013, Benjamin Herrenschmidt wrote: >> >> > The OF code uses irqsafe locks everywhere except in a handful of functions >> > for no obvious reasons. Since the conversion from the old rwlocks, this >> > now triggers lockdep warnings when used at interrupt time. At least one >> > driver (ibmvscsi) seems to be doing that from softirq context. >> > >> > This converts the few non-irqsafe locks into irqsafe ones, making them >> > consistent with the rest of the code. >> >> Fun. https://lkml.org/lkml/2013/2/4/416 seems to have got lost >> >> > Signed-off-by: Benjamin Herrenschmidt >> > CC: [v3.9+] >> >> Acked-by: Thomas Gleixner >> >> > --- >> > >> > Note: It's silly to access the device-tree at interrupt time in most cases, >> > and we should probably fix ibmvscsi, but for the time being, let's fix the >> >> Right. >> >> > obvious bug. Thomas, this can probably still go into 3.10... If not, I've >> > CCed stable. >> >> Should go through Grant I think. > > Applied, thanks. FWIW: Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
From: Linus Walleij Date: Fri, 7 Jun 2013 09:31:58 +0200 > On Thu, Jun 6, 2013 at 10:50 AM, Mark Brown wrote: >> On Thu, Jun 06, 2013 at 11:29:39AM +0530, Mugunthan V N wrote: >>> On 6/6/2013 12:53 AM, Mark Brown wrote: >> >>> >Linus Walleij posted some patches which factor the state setting code >>> >out into generic functions earlier on today - it probably makes sense to >>> >pick those up rather than open coding >> >>> But this can go in as Linus Walleij's patch is not accepted yet. >>> Once that is >>> accepted and present in net git repo I will submit a separate patch to use >>> those APIs from pin ctrl core. >> >> Linus' change has pretty much gone in already but in any case what would >> be sensible here would be to write this in turns of Linus' changes and >> then send the patch to him to add to his series so it can go in via the >> same route. One of the major reasons for the patch was that lots of >> people were querying the amount of noise caused by this sort of change. > > I agree. We should be able to settle on the new core API quite soon, > then I can carry the patch to this driver if you obtain David's ACK. If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ethernet/arc/arc_emac - Add new driver
From: Alexey Brodkin
Date: Tue, 4 Jun 2013 16:21:50 +0400
> +{
> + struct arc_emac_priv *priv = netdev_priv(net_dev);
> + struct phy_device *phydev = priv->phy_dev;
> + u32 reg;
> +
> + int status_change = 0;
Do not add empty lines amongst the top-level variable declarations
of a function. Fix this in the entire driver, as needed.
> + netdev_warn(net_dev,
> + "Speed (%d) is not 10/100?\n", phydev->speed);
Functions calls on multiple lines must have the arguments
aligned properly on the second and subsequent lines, this
means:
function(arg1, arg2,
arg3, arg4);
You must use the appropriate number of TAB and space characters
to achieve this proper column alignment, rather than only using
TAB characters as you have done here.
Audit and fix this in your entire driver.
> +static int arc_emac_get_settings(struct net_device *net_dev,
> + struct ethtool_cmd *cmd)
The argument indention rules above apply to function definitions
as well.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] net: sun4i-emac: fix a typo in emac_probe()
From: Maxime Ripard Date: Tue, 4 Jun 2013 15:24:08 +0200 > On Mon, Jun 03, 2013 at 09:36:52PM +0800, Wei Yongjun wrote: >> From: Wei Yongjun >> >> Just fixed a typo in emac_probe(). >> >> Signed-off-by: Wei Yongjun ... > Acked-by: Maxime Ripard Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH 0/8] add phy driver for Atheros AR8031 and CPSW phy-mode DT enhancement
From: Mugunthan V N Date: Tue, 4 Jun 2013 11:40:03 +0530 > This patch series adds the following feature > * Atheros phy driver code cleanup > * Add AT8031 phy driver to at803x driver > * Add RGMII tx delay support via phy_if > * Add phy_if DT enhancement to CPSW Driver and DT Series applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] net: micrel : ks8851-ml: add dt support
From: Jean-Christophe PLAGNIOL-VILLARD Date: Fri, 24 May 2013 11:01:22 +0200 > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v2 1/6] net: cpsw: enhance pinctrl support
From: Mugunthan V N Date: Thu, 23 May 2013 18:00:23 +0530 > From: Hebbar Gururaja > > Amend cpsw controller to optionally take a pin control handle and set > the state of the pins to: > > - "default" on boot, resume > - "sleep" on suspend() > > This should make it possible to optimize energy usage for the pins > for the suspend/resume cycle. > > If any of the above pin states are missing in dt, a warning message > about the missing state is displayed. > If certain pin-states are not available, to remove this warning message > pass respective state name with null phandler. > > Signed-off-by: Hebbar Gururaja > Signed-off-by: Mugunthan V N This still needs some work: > + /* > + * Since we continue even when pinctrl node is not found, > + * Invalidate pins as not available. This is to make sure that > + * IS_ERR(pins_xxx) results in failure when used. > + */ The second, third, fourth, and fifth lines are not tabbed correctly. They should all be two TABs and a SPACE. Secondly, comments in the networking are to be formatted: /* Like * this. */ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next resend PATCH 1/6] net: cpsw: enhance pinctrl support
From: "Hebbar, Gururaja" Date: Thu, 23 May 2013 11:28:38 + > On Thu, May 23, 2013 at 12:27:41, David Miller wrote: >> From: Mugunthan V N >> Date: Tue, 21 May 2013 15:24:58 +0530 >> >> > + priv->pins_default = pinctrl_lookup_state(priv->pinctrl, >> > + PINCTRL_STATE_DEFAULT); >> >> This is not indented correctly. >> >> Argument on the second, and subsequent, lines of a function call >> must start at the first column after the openning parenthesis of >> the function call itself. > > Well, if I am correct, doing so will make the line cross 80 character limit. > If you could (please I ask), can you let me know how it can be handled in > above situation. I will make the changes/corrections and re-send it. > > Thanks a lot in advance. Avoid the deep indentation by coding the basic block into a helper function. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next resend PATCH 1/6] net: cpsw: enhance pinctrl support
From: Mugunthan V N Date: Tue, 21 May 2013 15:24:58 +0530 > + priv->pins_default = pinctrl_lookup_state(priv->pinctrl, > + PINCTRL_STATE_DEFAULT); This is not indented correctly. Argument on the second, and subsequent, lines of a function call must start at the first column after the openning parenthesis of the function call itself. Please audit for this problem in your entire patch series, fix it up, and resubmit the full set of patches. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] net: dm9000: Allow instantiation using device tree
From: Tomasz Figa Date: Mon, 20 May 2013 21:16:58 +0200 > This patch adds Device Tree support to dm9000 driver. > > Signed-off-by: Tomasz Figa APplied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] gianfar: add missing iounmap() on error in gianfar_ptp_probe()
From: Wei Yongjun Date: Fri, 17 May 2013 16:25:34 +0800 > From: Wei Yongjun > > Add the missing iounmap() before return from gianfar_ptp_probe() > in the error handling case. > > Signed-off-by: Wei Yongjun Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net/spider_net: fix error return code in spider_net_open()
From: Wei Yongjun Date: Tue, 7 May 2013 20:16:00 +0800 > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as done elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: of_mdio: fix behavior on missing phy device
From: Sebastian Hesselbarth Date: Tue, 7 May 2013 11:49:31 +0200 > of_mdiobus_register creates a phy_device even if get_phy_device failed > to create it previously. This causes indefinite polling on non-existent > PHYs. This fix makes of_mdio_register rely on get_phy_device to > properly create the device or fail otherwise. > > Signed-off-by: Sebastian Hesselbarth Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/7] mv643xx_eth: device tree bindings
Two things: 1) None of your postings make the mailing lists because your CC: line is too large, and we block large ones because those are %99 of SPAM. It really isn't reasonable to CC: so many people, and I do understand that you're just sifting email addresses from MAINTAINERS or whatever, but just use the appropriate mailing lists and the absolute most direct developer(s). Probably just the person who you believe should apply this patch. 2) Networking feature patch submissions are closed, as per: http://marc.info/?l=linux-netdev&m=136730964130303&w=2 Therefore please resubmit this after the merge window is closed and I have explicitly announced that the net-next tree is open again for submissions. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] serial: sunsu: add missing platform_driver_unregister() when module exit
From: Wei Yongjun Date: Sat, 27 Apr 2013 18:13:16 +0800 > From: Wei Yongjun > > We have registered platform driver when module init, and > need unregister it when module exit. > > Signed-off-by: Wei Yongjun Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH 0/6] Adding pinctrl PM support for CPSW and Davinci MDIO drivers
Please read: http://marc.info/?l=linux-netdev&m=136730964130303&w=2 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH 1/3] drivers: of: add phy fixup support in DT
From: Mugunthan V N Date: Mon, 22 Apr 2013 23:50:36 +0530 > In earlier case phy fixup are added in board file as this is no more the case > so adding support for phy register fixup in Device Tree > > Signed-off-by: Mugunthan V N When people put a series of undocumented PHY register writes using constants, we tell them it's firmware. If these PHY registers are actually documented in the driver, write a function in that driver which does the programming sequence, then add a property that the driver looks for in order to determine whether to call that sequence or not. I don't want people putting random PHY raw programming sequences and other crap like that into the OF device nodes. It's extremely inelegant and inviting abuse. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch -next] net: calxedaxgmac: fix condition in xgmac_set_features()
From: Dan Carpenter Date: Thu, 25 Apr 2013 10:44:20 +0300 > The "changed" variable should be a 64 bit type, otherwise it can't store > all the features. The way the code is now the test for whether > NETIF_F_RXCSUM changed is always false and we return immediately. > > Signed-off-by: Dan Carpenter Applied, thanks Dan. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net/at91_ether: fix error return code in at91ether_probe()
From: Wei Yongjun Date: Fri, 12 Apr 2013 10:42:40 +0800 > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as returned elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] net: mv643xx_eth: use managed clk and allocation
From: Sebastian Hesselbarth Date: Thu, 11 Apr 2013 11:29:32 +0200 > With introduction of common clock framework and the ability to provide > gated clocks, mv643xx_eth required calls to get and enable these clock > gates on some platforms. Back then, common clock framework api wasn't > safe for architectures without support for common clocks. This has > changed now and there are also managed (devm_) counterparts for clock > related functions. > > The second patch in this series, also converts kzalloc to devm_kzalloc > where applicable. > > Both patches have been sent to the corresponding mailing lists as > individual patches before. To get the order required to apply them right, > this patch set combines both patches into one set. Both applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] net: mvmdio: add clocks property to binding documentation
From: Sebastian Hesselbarth
Date: Thu, 11 Apr 2013 11:24:48 +0200
> Commit 3d604da1e9547c09c9dcc0ee443c306c9ae1a480
> ("net: mvmdio: get and enable optional clock")
>
> was missing an update of the corresponding device tree binding
> documentation. This patch adds the clocks property to mvmdio
> binding documentation.
>
> Signed-off-by: Sebastian Hesselbarth
Applied.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: mvmdio: add clocks property to binding documentation
From: Sebastian Hesselbarth Date: Wed, 10 Apr 2013 19:36:29 +0200 > Patch "net: mvmdio: get and enable optional clock" was missing an > update of the corresponding device tree binding documentation. This > patch adds the clocks property to mvmdio binding documentation. > > Signed-off-by: Sebastian Hesselbarth Please reference commits by SHA1 ID as well as the commit log message header line (the latter of which should be inside of parenthesis and double quotes). Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: of_mdio: scan mdiobus for PHYs without reg property
From: Sebastian Hesselbarth Date: Sun, 7 Apr 2013 13:09:48 +0200 > Using DT for mdiobus and ethernet-phy requires to know the PHY address, which > is hard to guess if you don't know it. This patch extends of_mdiobus_register > to scan mdiobus for PHYs if reg property of the corresponding node is not set. > This also allows to have phy nodes in SoC DT files where the reg property can > be overwritten in the board file later. To encourage people to finally set the > actual phy address, the mdiobus scan is noisier than required. > > Signed-off-by: Sebastian Hesselbarth Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/6] Generic PHY Framework
From: Kishon Vijay Abraham I Date: Wed, 3 Apr 2013 12:05:30 +0530 > This patch series is about drivers/phy which will be used for now by > usb, sata and maybe some video PHY's. Network itself has a > comprehensive PHY in drivers/net/phy which we'd like to merge it with > drivers/phy so that we have all the phy stuff in drivers/phy but we > are not planning too far ahead here. Ok, that makes sense, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/6] Generic PHY Framework
From: Kishon Vijay Abraham I Date: Wed, 3 Apr 2013 11:29:53 +0530 > Hi, > > On Friday 29 March 2013 12:01 AM, David Miller wrote: >> >> You really need to CC: net...@vger.kernel.org rather than me >> explicitly >> on this patch set. > > I was CC'ing whatever get_maintainer shows. I'll make sure to CC > net...@vger.kernel.org though there's nothing related to network in > this patch series (Maybe sometime in the future it'll be used). What about drivers/net/phy isn't networking? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] Provide empty functions if OF_NET is not configured
From: Guenter Roeck Date: Tue, 2 Apr 2013 12:35:06 -0700 > Provide empty functions for of_get_phy_mode() and of_get_mac_address() > if OF_NET is not configured. Modify affected drivers to rely on the > now available functions. All applied, but please post your patches against the appropriate tree. In net-next, fec.c has been renamed to fec_main.c so I had to adjust your patch so that it would apply correctly. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of_net.h: Provide dummy functions if OF_NET is not configured
From: Rob Herring Date: Mon, 01 Apr 2013 14:14:10 -0500 > On 04/01/2013 02:01 PM, Guenter Roeck wrote: >> On Mon, Apr 01, 2013 at 01:44:24PM -0500, Rob Herring wrote: >>> On 04/01/2013 01:19 PM, Guenter Roeck wrote: of_get_mac_address() and of_get_phy_mode() are only provided if OF_NET is configured. While most callers check for the define, not all do, and those who do require #ifdef around the code. For those who don't, the missing check can result in errors such as >>> >>> How about removing the ifdef from those callers? >>> >> That would be the next step, after/if this one is accepted. >> If not, it doesn't make sense to waste my time. > > Assuming that is done: > > Acked-by: Rob Herring > > Presumably with the follow-on patches, this can go in thru the net tree. Indeed, please resubmit this with the follow-on cleanups. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 0/6] Generic PHY Framework
You really need to CC: net...@vger.kernel.org rather than me explicitly on this patch set. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH net-next] dsa: add device tree bindings to register DSA switches
From: Florian Fainelli Date: Fri, 22 Mar 2013 21:50:50 +0100 > This patch adds support for registering DSA switches using Device Tree > bindings. Note that we support programming the switch routing table even > though no in-tree user seems to require it. I tested this on Armada 370 > with a Marvell 88E6172 (not supported by mainline yet). > > Signed-off-by: Florian Fainelli Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4 v3] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Fri, 22 Mar 2013 14:39:24 +0100 > This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver > instead of rolling its own implementation. As a result, all users of this > mv643xx_eth driver are converted to register an "orion-mdio" platform_device. > The mvmdio driver is also updated to support an interrupt line which reports > SMI error/completion, and to allow traditionnal platform device registration > instead of just device tree. > > David, I think it makes sense for you to merge all of this, since we do > not want the architecture files to be desynchronized from the mv643xx_eth to > avoid runtime breakage. The potential for merge conflicts should be very > small. Series applied to net-next, thanks Florian. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: sh-eth: Use pr_err instead of printk
From: Simon Horman Date: Thu, 21 Mar 2013 17:46:55 +0900 > From: Nobuhiro Iwamatsu > > Signed-off-by: Nobuhiro Iwamatsu > Signed-off-by: Simon Horman Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: fec: make local function fec_poll_controller() static
From: Wei Yongjun Date: Wed, 20 Mar 2013 23:06:11 +0800 > From: Wei Yongjun > > fec_poll_controller() was not declared. It should be static. > > Signed-off-by: Wei Yongjun Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] net: ethernet: davinci_emac: make local function emac_poll_controller() static
From: Wei Yongjun Date: Wed, 20 Mar 2013 23:01:45 +0800 > From: Wei Yongjun > > emac_poll_controller() was not declared. It should be static. > > Signed-off-by: Wei Yongjun Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] lpc_eth: fix error return code in lpc_eth_drv_probe()
From: Wei Yongjun Date: Wed, 20 Mar 2013 20:21:48 +0800 > From: Wei Yongjun > > Fix to return a negative error code from the error handling > case instead of 0, as returned elsewhere in this function. > > Signed-off-by: Wei Yongjun Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Fri, 15 Mar 2013 13:53:10 +0100 > Le 03/15/13 13:55, David Miller a écrit : >> From: David Miller >> Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) >> >>> From: Florian Fainelli >>> Date: Thu, 14 Mar 2013 19:08:31 +0100 >>> >>>> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus >>>> driver >>>> instead of rolling its own implementation. As a result, all users of >>>> this >>>> mv643xx_eth driver are converted to register an "orion-mdio" >>>> platform_device. >>>> The mvmdio driver is also updated to support an interrupt line which >>>> reports >>>> SMI error/completion, and to allow traditionnal platform device >>>> registration >>>> instead of just device tree. >>>> >>>> David, I think it makes sense for you to merge all of this, since we >>>> do >>>> not want the architecture files to be desynchronized from the >>>> mv643xx_eth to >>>> avoid runtime breakage. The potential for merge conflicts should be >>>> very small. >>> >>> All applied to net-next, thanks. >> >> Actually, reverted. Please send me code which actually compiles: >> >> drivers/net/ethernet/marvell/mvmdio.c: In function >> ‘orion_mdio_wait_ready’: >> drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ >> undeclared (first use in this function) >> drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared >> identifier is reported only once for each function it appears in >> drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: >> drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ >> undeclared (first use in this function) >> make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 >> >> And don't use Kconfig dependencies to work around this, fix it >> properly. > > Is there any platform out there for which we do not have a NO_IRQ > definition by now? If so, what is it? Obviously if x86_64 doesn't even build your changes, that is one such platform. Also, is grep not working on your computer? Platforms are absolutely no required to have this define, zero is the only valid "no IRQ" which is portable in any way. This is an old and tired topic, portable code does not use NO_IRQ, and that's simply the end of it. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: David Miller Date: Fri, 15 Mar 2013 08:53:21 -0400 (EDT) > From: Florian Fainelli > Date: Thu, 14 Mar 2013 19:08:31 +0100 > >> This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver >> instead of rolling its own implementation. As a result, all users of this >> mv643xx_eth driver are converted to register an "orion-mdio" platform_device. >> The mvmdio driver is also updated to support an interrupt line which reports >> SMI error/completion, and to allow traditionnal platform device registration >> instead of just device tree. >> >> David, I think it makes sense for you to merge all of this, since we do >> not want the architecture files to be desynchronized from the mv643xx_eth to >> avoid runtime breakage. The potential for merge conflicts should be very >> small. > > All applied to net-next, thanks. Actually, reverted. Please send me code which actually compiles: drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_wait_ready’: drivers/net/ethernet/marvell/mvmdio.c:70:28: error: ‘NO_IRQ’ undeclared (first use in this function) drivers/net/ethernet/marvell/mvmdio.c:70:28: note: each undeclared identifier is reported only once for each function it appears in drivers/net/ethernet/marvell/mvmdio.c: In function ‘orion_mdio_probe’: drivers/net/ethernet/marvell/mvmdio.c:242:24: error: ‘NO_IRQ’ undeclared (first use in this function) make[4]: *** [drivers/net/ethernet/marvell/mvmdio.o] Error 1 And don't use Kconfig dependencies to work around this, fix it properly. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/4] mv643xx_eth: use mvmdio MDIO bus driver
From: Florian Fainelli Date: Thu, 14 Mar 2013 19:08:31 +0100 > This patch converts the mv643xx_eth driver to use the mvmdio MDIO bus driver > instead of rolling its own implementation. As a result, all users of this > mv643xx_eth driver are converted to register an "orion-mdio" platform_device. > The mvmdio driver is also updated to support an interrupt line which reports > SMI error/completion, and to allow traditionnal platform device registration > instead of just device tree. > > David, I think it makes sense for you to merge all of this, since we do > not want the architecture files to be desynchronized from the mv643xx_eth to > avoid runtime breakage. The potential for merge conflicts should be very > small. All applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/5] cpsw interrupt pacing and get/set phy setting implementation
From: Mugunthan V N Date: Tue, 12 Mar 2013 14:46:33 +0530 > This patch serires implements the following features in CPSW driver > * get/set phy link settings > * interrupt pacing > * get phy id via ioctl cmd SIOCGMIIPHY > > Changes from initial version > * Made active-slave common for cpts, ethtool and SIOCGMIIPHY ioctl > * Cleaned CPSW DT binding documentation by seperating slave nodes > under sub-section > * implemented get phy id via ioctl cmd SIOCGMIIPHY Series applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drivers: net: Remove remaining alloc/OOM messages
From: Joe Perches Date: Thu, 07 Feb 2013 13:46:27 -0800 > alloc failures already get standardized OOM > messages and a dump_stack. > > For the affected mallocs around these OOM messages: > > Converted kmallocs with multiplies to kmalloc_array. > Converted a kmalloc/memcpy to kmemdup. > Removed now unused stack variables. > Removed unnecessary parentheses. > Neatened alignment. > > Signed-off-by: Joe Perches Applied, thanks Joe. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH next] OF: convert devtree lock from rw_lock to raw spinlock
From: Paul Gortmaker Date: Mon, 4 Feb 2013 11:05:21 -0500 > From: Thomas Gleixner > > With the locking cleanup in place (from "OF: Fixup resursive > locking code paths"), we can now do the conversion from the > rw_lock to a raw spinlock as required for preempt-rt. > > The previous cleanup and the this conversion were originally > separate since they predated when mainline got raw spinlock (in > commit c2f21ce2e31286a "locking: Implement new raw_spinlock"). > > So, at that point in time, the cleanup was considered plausible > for mainline, but not this conversion. In any case, we've kept > them separate as it makes for easier review and better bisection. > > Signed-off-by: Thomas Gleixner > [PG: taken from preempt-rt, update subject & add a commit log] > Signed-off-by: Paul Gortmaker Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [patch] tg3: missing break statement in tg3_get_5720_nvram_info()
From: Dan Carpenter Date: Fri, 11 Jan 2013 09:57:33 +0300 > There is a missing break statement so FLASH_5762_EEPROM_HD gets treated > like FLASH_5762_EEPROM_LD. > > Signed-off-by: Dan Carpenter Applied, thanks Dan. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] sparc: Enable OF functionality for sparc for i2c and spi
From: Grant Likely Date: Tue, 4 Dec 2012 21:49:26 + > On Tue, Dec 4, 2012 at 9:10 PM, David Miller wrote: >> From: Grant Likely >> Date: Tue, 4 Dec 2012 14:44:57 + >> >>> On Tue, Dec 4, 2012 at 2:09 PM, Andreas Larsson wrote: >>>> This series removes the dependency on !SPARC for OF_I2C and removes the >>>> depencency of !defined(CONFIG_SPARC) for the function >>>> of_register_spi_devices. I find no reason for these to be unavailable >>>> for sparc. >>>> >>>> I am not sure if these should go through the sparc tree or the >>>> corresponding subsystem trees. >>> >>> They should go through the subsystem trees. >> >> I'll take this into the sparc tree after some build testing, thanks. > > I'd prefer to take the SPI one through my tree, but I won't get my > knickers in a knot if you insist. That's fine: Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] of_i2c: sparc: Allow OF_I2C for sparc
From: Andreas Larsson Date: Tue, 4 Dec 2012 15:09:37 +0100 > Signed-off-by: Andreas Larsson Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] sparc: Enable OF functionality for sparc for i2c and spi
From: Grant Likely Date: Tue, 4 Dec 2012 14:44:57 + > On Tue, Dec 4, 2012 at 2:09 PM, Andreas Larsson wrote: >> This series removes the dependency on !SPARC for OF_I2C and removes the >> depencency of !defined(CONFIG_SPARC) for the function >> of_register_spi_devices. I find no reason for these to be unavailable >> for sparc. >> >> I am not sure if these should go through the sparc tree or the >> corresponding subsystem trees. > > They should go through the subsystem trees. I'll take this into the sparc tree after some build testing, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/address: sparc: Declare of_iomap as an extern function for sparc again
From: Andreas Larsson Date: Fri, 23 Nov 2012 12:24:09 +0100 > This bug-fix makes sure that of_iomap is defined extern for sparc so that the > sparc-specific implementation of_iomap is once again used when including > include/linux/of_address.h in a sparc context. OF_GPIO that is now available > for > sparc relies on this. > > The bug was inadvertently introduced in a850a75, "of/address: add empty static > inlines for !CONFIG_OF", that added a static dummy inline for of_iomap when > !CONFIG_OF_ADDRESS. However, CONFIG_OF_ADDRESS is never defined for sparc, but > there is a sparc-specific implementation > /arch/sparc/kernel/of_device_common.c. > > This fix takes the same approach as 0bce04b that solved the equivalent problem > for of_address_to_resource. > > Signed-off-by: Andreas Larsson Grant, can you possibly merge this to Linus while I'm travelling? That would help me a lot. Thanks! ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
From: Srinivas KANDAGATLA Date: Fri, 16 Nov 2012 10:33:59 + > From: Srinivas Kandagatla > > When the mdio-gpio driver is probed via device trees, the platform > device id is set as -1, However the pdev->id is re-used as bus-id for > while creating mdio gpio bus. > So > For device tree case the mdio-gpio bus name appears as "gpio-" > where as > for non-device tree case the bus name appears as "gpio-" > > Which means the bus_id is fixed in device tree case, so we can't have > two mdio gpio buses via device trees. Assigning a logical bus number > via device tree solves the problem and the bus name is much consistent > with non-device tree bus name. > > Without this patch > 1. we can't support two mdio-gpio buses via device trees. > 2. we should always pass gpio- as bus name to phy_connect, very > different to non-device tree bus name. > > So, setting up the bus_id via aliases from device tree is the right > solution and other drivers do similar thing. > > Signed-off-by: Srinivas Kandagatla Applied, thank you. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] drivers/of: Constify device_node->name and ->path_component_name
From: Grant Likely Date: Fri, 16 Nov 2012 14:20:25 + > Neither of these should ever be changed once set. Make them const and > fix up the users that try to modify it in-place. In one case > kmalloc+memcpy is replaced with kstrdup() to avoid modifying the string. > > Build tested with defconfigs on ARM, PowerPC, Sparc, MIPS, x86 among > others. > > Signed-off-by: Grant Likely Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5 0/7] ARM: AM33XX: net: Add DT support to CPSW and MDIO driver
From: Mugunthan V N Date: Thu, 15 Nov 2012 00:37:53 +0530 > This patch-series adds support for, > > [1/7]: Typo mistake in CPSW driver while invoking runtime_pm api's > > [2/7]: Adds parent<->child relation between CPSW & MDIO module inside cpsw >driver, as in case of AM33XX, the resources are shared and common >register bit-field is provided to control module/clock enable/disable, >makes it difficult to handle common resource. > >So the solution here is, to create parent<->child relation between > them. > > [3/7]: cpsw: simplify the setup of the register pointers > > [4/7]: cpsw: Kernel warn fix during suspend > > [5/7]: Add hwmod entry for MDIO module, required for MDIO driver. > > [6/7]: Enable CPSW support to omap2plus_defconfig > > [7/7]: Add DT device nodes for both CPSW and MDIO modules in am33xx.dtsi, >am335x-evm.dts and am335x-bone.dts file > > This patch series has been created on top of net-next/master and tested > on BeagleBone platform for NFS boot and basic ping test cases. All applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3.7.0-rc4] of/net/mdio-gpio: Fix pdev->id issue when using devicetrees.
From: Srinivas KANDAGATLA Date: Tue, 13 Nov 2012 14:26:13 + > From: Srinivas Kandagatla > > When the mdio-gpio driver is probed via device trees, the platform > device id is set as -1, However the id is re-used in the code while > creating an mdio bus. > So, setting up the id via aliases from device tree is a sensible > solution to fix this issue. > > Signed-off-by: Srinivas Kandagatla This seems rather pointless unless you also update every single device tree out there. Also you need to describe what are the ramifications of this problem otherwise it is impossible to figure out how serious this change is. Does it prevent probing? Does it cause a crash? Basically, what I'm saying is that this is a very poor submission and you need to substantially improve it and communicate better. If the problem is basically benign, then you should target this change to net-next instead of the net tree, along with the necessary dt file updates. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drivers/of: Constify device_node->name and ->path_component_name
From: Grant Likely Date: Wed, 14 Nov 2012 22:42:26 + > On Wed, Nov 14, 2012 at 10:33 PM, David Miller wrote: >> >> You're making other changes here, such as the kstrdup() stuff, >> seperate that into another patch. > > It's part of the same change. The original code was allocating a > buffer, saving the pointer in the name field and then modifying it. > Making the code to a kstrdup() gets rid of modifying the const buffer. Please mention that in your commit message then, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drivers/of: Constify device_node->name and ->path_component_name
You're making other changes here, such as the kstrdup() stuff, seperate that into another patch. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2 v2] net: at91_ether add dt and pinctrl support
From: Jean-Christophe PLAGNIOL-VILLARD Date: Mon, 5 Nov 2012 08:30:15 +0100 > Hi, > > v2: fix typo in doc + miising empty line > > This patch serie add dt and pinctrl support to the at91 ether > > this is need to use the network on at91rm9200 as we now have dt > support on it > > Jean-Christophe PLAGNIOL-VILLARD (2): > net: at91_ether: add dt support > net: at91_ether: add pinctrl support Series applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] net: ti cpsw ethernet: allow reading phy interface mode from DT
From: Daniel Mack Date: Mon, 01 Oct 2012 23:15:38 +0200 > On 01.10.2012 23:11, David Miller wrote: >> From: Daniel Mack >> Date: Wed, 26 Sep 2012 19:24:27 +0200 >> >>> Allow users to specify the phy interface of the CPSW slaves. The new >>> node parameter is called "phy_if_mode" and is optional. The original >>> behaviour of the driver is preserved when not given. >>> >>> Signed-off-by: Daniel Mack >> >> Applied, thanks. >> > > Eh, no - sorry. My original understanding was that a bit in the cpsw > registers has to be set only when a certain physical phy mode is in use. > Hence we would have needed a way to pass that information in via DT. But > as Mugunthan pointed out, that bit must always be set, and the cpsw > slaves can stay agnostic to the actual phy mode. > > So that patch isn't needed. Sorry for the confusion. Ok I'll revert. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] net: ti cpsw ethernet: allow reading phy interface mode from DT
From: Daniel Mack Date: Wed, 26 Sep 2012 19:24:27 +0200 > Allow users to specify the phy interface of the CPSW slaves. The new > node parameter is called "phy_if_mode" and is optional. The original > behaviour of the driver is preserved when not given. > > Signed-off-by: Daniel Mack Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] netdev: octeon: fix return value check in octeon_mgmt_init_phy()
From: Wei Yongjun Date: Fri, 28 Sep 2012 13:04:21 +0800 > From: Wei Yongjun > > In case of error, the function of_phy_connect() returns NULL > pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] netdev: pasemi: fix return value check in pasemi_mac_phy_init()
From: Wei Yongjun Date: Thu, 27 Sep 2012 13:51:58 +0800 > From: Wei Yongjun > > In case of error, the function of_phy_connect() returns NULL > pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] drivers: phy: add generic PHY framework
All networking patches must be submitted to net...@vger.kernel.org Thank you. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] [v3] netdev/phy: add MDIO bus multiplexer driven by a memory-mapped device
From: Timur Tabi Date: Fri, 24 Aug 2012 14:10:53 -0500 > Add support for an MDIO bus multiplexer controlled by a simple memory-mapped > device, like an FPGA. The device must be memory-mapped and contain only > 8-bit registers (which keeps things simple). > > Tested on a Freescale P5020DS board which uses the "PIXIS" FPGA attached > to the localbus. > > Signed-off-by: Timur Tabi Applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3.6.0-rc3 2/2] of/mdio-gpio: Simplify the way device tree support is implemented.
From: Srinivas KANDAGATLA Date: Fri, 24 Aug 2012 12:59:17 +0100 > From: Srinivas Kandagatla > > This patch cleans up the way device tree support is added in mdio-gpio > driver. I found lot of code duplication which is not necessary. > Also strangely a new platform driver was also introduced for device tree > support. All this forced me to do this cleanup patch. > After this patch, the driver probe checks the of_node pointer to get the > data from device tree. > > Signed-off-by: Srinivas Kandagatla Applied to net-next. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3.6.0-rc3 1/2] of/mdio: Add dummy functions in of_mdio.h.
From: Srinivas KANDAGATLA Date: Fri, 24 Aug 2012 12:58:59 +0100 > From: Srinivas Kandagatla > > This patch adds dummy functions in of_mdio.h, so that driver need not > ifdef there code with CONFIG_OF. > > Signed-off-by: Srinivas Kandagatla Applied to net-next. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] [v2] netdev/phy: add MDIO bus multiplexer driven by a memory-mapped device
From: Stephen Warren Date: Fri, 24 Aug 2012 12:56:05 -0600 > In the I2C case, the address spaces are disjoint, so there's never any > mapping between them, so there's no need for ranges. > > Any time the child address space is intended to be part of the parent's > address space, I believe ranges is supposed to be specified, perhaps > even mandatory, even if the translation is 1:1. Regardless, you really can't just generically translate ranges in some universal way and expect it to work in all cases. You need bus specific drivers to deal with various special cases. See the *_map() methods implemented in: arch/sparc/kernel/of_device_64.c for example. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] [v2] netdev/phy: skip disabled mdio-mux nodes
From: Timur Tabi Date: Tue, 14 Aug 2012 18:20:24 -0500 > The mdio-mux driver scans all child mdio nodes, without regard to whether > the node is actually used. Some device trees include all possible > mdio-mux nodes and rely on the boot loader to disable those that are not > present, based on some run-time configuration. Those nodes need to be > skipped. > > Signed-off-by: Timur Tabi Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] dt: introduce for_each_available_child_of_node, of_get_next_available_child
From: Timur Tabi Date: Tue, 14 Aug 2012 18:20:23 -0500 > Macro for_each_child_of_node() makes it easy to iterate over all of the > children for a given device tree node, including those nodes that are > marked as unavailable (i.e. status = "disabled"). > > Introduce for_each_available_child_of_node(), which is like > for_each_child_of_node(), but it automatically skips unavailable nodes. > This also requires the introduction of helper function > of_get_next_available_child(), which returns the next available child > node. > > Signed-off-by: Timur Tabi Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Add device tree support for davinci_mdio driver and fix cpsw DT binding documentation
From: Mugunthan V N Date: Mon, 6 Aug 2012 20:35:56 +0530 > This patch set adds support for device tree for Davinci MDIO driver and fixes > CPSW DT binding documentation to make it copy pastable to dts file. > > This patch set is tested with the following git tree on AM335X Beagle Bone > https://github.com/hvaibhav/am335x-linux/tree/am335x-upstream-staging-cpsw > > Mugunthan V N (2): > drivers: net: ethernet: davince_mdio: device tree implementation > documentation: dt: bindings: cpsw: fixing the examples for directly > using it in dts file Applied to net-next, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [net-next PATCH v7] net: ethernet: davinci_emac: add OF support
From: Anatolij Gustschin Date: Tue, 17 Jul 2012 12:34:24 +0200 > From: Heiko Schocher > > add OF support for the davinci_emac driver. > > Signed-off-by: Heiko Schocher > Acked-by: Sekhar Nori > Signed-off-by: Anatolij Gustschin Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/5] fec driver updates
From: Shawn Guo Date: Wed, 27 Jun 2012 21:45:19 +0800 > Changes since v1: > * Add one patch to use devm_gpio_request_one > * Have a separate patch to fix phy-reset-gpios property in binding > document > * Change phy-reset-interval to phy-reset-duration > * Add a sanity check on phy-reset-duration value All applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] netdev/phy: 10G PHY support.
From: David Daney
Date: Wed, 27 Jun 2012 10:33:34 -0700
> From: David Daney
>
> The only non-cosmetic change from v1 is to pass an additional argument
> to get_phy_device() that indicates that the PHY uses 802.3 clause 45
> signaling, previously I had been using a high order bit of the addr
> parameter for this.
>
> There are also changes from v1 in the code and comment formatting.
> These should now be closer to what David Miller prefers.
Applied, but I had to add the following warning fixup:
phy: Fix warning in get_phy_device().
drivers/net/phy/phy_device.c: In function ‘get_phy_device’:
drivers/net/phy/phy_device.c:340:14: warning: ‘phy_id’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
GCC can't see that when we return zero we always initialize
phy_id and that's the only path where we use it.
Initialize phy_id to zero to shut it up.
Signed-off-by: David S. Miller
---
drivers/net/phy/phy_device.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index ef4cdee..47e02e7 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -327,9 +327,9 @@ static int get_phy_id(struct mii_bus *bus, int addr, u32
*phy_id,
*/
struct phy_device *get_phy_device(struct mii_bus *bus, int addr, bool is_c45)
{
- struct phy_device *dev = NULL;
- u32 phy_id;
struct phy_c45_device_ids c45_ids = {0};
+ struct phy_device *dev = NULL;
+ u32 phy_id = 0;
int r;
r = get_phy_id(bus, addr, &phy_id, is_c45, &c45_ids);
--
1.7.10.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] netdev/phy: Handle IEEE802.3 clause 45 Ethernet PHYs
From: David Daney Date: Mon, 25 Jun 2012 16:48:40 -0700 > Therefore, I am going to propose that we add a 'flags' parameter to > get_phy_device() and change the (two) callers. Since there is only one flag, make it simply a bool for now. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] netdev/phy: Handle IEEE802.3 clause 45 Ethernet PHYs
From: David Daney Date: Mon, 25 Jun 2012 16:11:23 -0700 > Do you realize that at the time get_phy_device() is called, there is > no PHY device? So there can be no attribute, nor are we passing a > register address. Neither of these suggestions apply to this > situation. > > We need to know a priori if it is c22 or c45. So we need to > communicate the type somehow to get_phy_device(). I chose an unused > bit in the addr parameter to do this, another option would be to add a > separate parameter to get_phy_device() specifying the type. Then pass it in to the get() routine and store the attribute there in the device we end up with. There are many parameters that go into a PHY register access, so we'll probably some day end up with a descriptor struct that the caller prepares on-stack to pass into the actual read/write ops via reference. > ... and this one too I guess. Really you and Linus should come to a > consensus on this one. We did come up with a consensus, which is that subsystem maintainers such as myself are at liberty to enforce localized coding style for the bodies of code they maintain. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/4] netdev/phy: Handle IEEE802.3 clause 45 Ethernet PHYs
From: David Daney Date: Fri, 22 Jun 2012 17:24:13 -0700 > From: David Daney > > The IEEE802.3 clause 45 MDIO bus protocol allows for directly > addressing PHY registers using a 21 bit address, and is used by many > 10G Ethernet PHYS. Already existing is the ability of MDIO bus > drivers to use clause 45, with the MII_ADDR_C45 flag. Here we add > struct phy_c45_device_ids to hold the device identifier registers > present in clause 45. struct phy_device gets a couple of new fields: > c45_ids to hold the identifiers and is_c45 to signal that it is clause > 45. > > Normally the MII_ADDR_C45 flag is ORed with the register address to > indicate a clause 45 transaction. Here we also use this flag in the > *device* address passed to get_phy_device() to indicate that probing > should be done with clause 45 transactions. > > EXPORT phy_device_create() so that the follow-on patch to of_mdio.c > can use it to create phy devices for PHYs, that have non-standard > device identifier registers, based on the device tree bindings. > > Signed-off-by: David Daney I see no value in having two ways to say that clause-45 transactions should be used. Either make it a PHY device attribute, or specify it in the address in the register accesses, but not both. Also your patch is full of coding style errors, I simply couldn't stomache applying this even if I agreed with the substance of the changes: > + i < ARRAY_SIZE(c45_ids->device_ids) && > + c45_ids->devices_in_package == 0; c45_ids on the second line should line up with the initial 'i' on the first line. > + c45_ids->devices_in_package = (phy_reg & 0x) << 16; > + > + > + reg_addr = MII_ADDR_C45 | i << 16 | 5; There is not reason in the world to have two empty lines there, it looks awful. > + /* > + * If mostly Fs, there is no device there, > + * let's get out of here. > + */ Format comments: /* Like * this. */ Not. /* * Like * this. */ > + c45_ids->device_ids[i] = (phy_reg & 0x) << 16; > + > + > + reg_addr = MII_ADDR_C45 | i << 16 | MII_PHYSID2; Two empty lines. This is extremely irritating, it looks like you had some kind of debugging code here and then were very lazy about removing it. > +/* > + * Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the > + * 21 bit IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy > + * chips. Also may be ORed into the device address in > + * get_phy_device(). > + */ Comment formatting. > +/* > + * phy_c45_device_ids: 802.3-c45 Device Identifiers > + * > + * devices_in_package: Bit vector of devices present. > + * device_ids: The device identifer for each present device. > + */ If you're going to list the struct members use the correct kerneldoc format to do so. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] netdev/phy: 10G PHY support.
As mentioned the other day in my announement, right now it is inappropriate to submit new feature patches. You will need to resend these changes when the net-next tree opens back up, please monitor the netdev list to learn when that has happened. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Daney Date: Wed, 2 May 2012 18:16:39 -0700 > From: David Daney > > The GPIO pins select which sub bus is connected to the master. > > Initially tested with an sn74cbtlv3253 switch device wired into the > MDIO bus. > > Signed-off-by: David Daney Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney Date: Wed, 2 May 2012 18:16:38 -0700 > From: David Daney > > This patch adds a somewhat generic framework for MDIO bus > multiplexers. It is modeled on the I2C multiplexer. > > The multiplexer is needed if there are multiple PHYs with the same > address connected to the same MDIO bus adepter, or if there is > insufficient electrical drive capability for all the connected PHY > devices. > > Conceptually it could look something like this: ... > This framework configures the bus topology from device tree data. The > mechanics of switching the multiplexer is left to device specific > drivers. > > The follow-on patch contains a multiplexer driven by GPIO lines. > > Signed-off-by: David Daney Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 1/3] netdev/of/phy: New function: of_mdio_find_bus().
From: David Daney Date: Wed, 2 May 2012 18:16:37 -0700 > From: David Daney > > Add of_mdio_find_bus() which allows an mii_bus to be located given its > associated the device tree node. > > This is needed by the follow-on patch to add a driver for MDIO bus > multiplexers. > > The of_mdiobus_register() function is modified so that the device tree > node is recorded in the mii_bus. Then we can find it again by > iterating over all mdio_bus_class devices. > > Because the OF device tree has now become an integral part of the > kernel, this can live in mdio_bus.c (which contains the needed > mdio_bus_class structure) instead of of_mdio.c. > > Signed-off-by: David Daney Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney Date: Sat, 21 Apr 2012 14:25:51 -0700 > If we were to specify the dependencies in both places, we gain nothing > other than duplication of information. Each Kconfig option enabling a module has to have appropriate dependencies. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 2/3] netdev/of/phy: Add MDIO bus multiplexer support.
From: David Daney Date: Wed, 18 Apr 2012 16:20:53 -0700 > +config MDIO_BUS_MUX > + tristate > + help > + This module provides a driver framework for MDIO bus > + multiplexers which connect one of several child MDIO busses > + to a parent bus. Switching between child busses is done by > + device specific drivers. > + This driver uses OF and OF_MDIO, and therefore need dependencies upon them. Otherwise it can be enabled in configurations which will result in build failures. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Daney Date: Wed, 18 Apr 2012 09:24:56 -0700 > B) Regenerate the entire set with said patch rolled in? Already regenerate patch sets with fixes incorporated into the original patches. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 3/3] netdev/of/phy: Add MDIO bus multiplexer driven by GPIO lines.
From: David Daney Date: Tue, 17 Apr 2012 10:32:46 -0700 > From: David Daney > > The GPIO pins select which sub bus is connected to the master. > > Initially tested with an sn74cbtlv3253 switch device wired into the > MDIO bus. > > Signed-off-by: David Daney Are you sure the Kconfig dependencies are sufficient? This code seems to depend upon OF, and in particular the OF_MDIO stuff. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] stmmac: Add device-tree support
From: Stefan Roese Date: Tue, 13 Mar 2012 15:56:37 +0100 > This patch adds support to configure the STMMAC ethernet driver via > device-tree instead of platform_data. > > Currently, only the properties needed on SPEAr600 are provided. All > other properties should be added once needed on other platforms. > > Signed-off-by: Stefan Roese > Cc: Giuseppe Cavallaro Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of: add NULL parameter check for of_device_is_available
From: Dong Aisheng Date: Tue, 13 Mar 2012 19:40:05 +0800 > From: Dong Aisheng > > This function will return 1 even the device node passed in > is NULL which is a little error-prone. > Change to return 0 if the device node passed in is NULL. > > Signed-off-by: Dong Aisheng I think this is a hard error and therefore BUG_ON(!device) is more appropriate. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 2/2] of: Make of_find_node_by_path() traverse /aliases for relative paths.
From: David Daney Date: Wed, 29 Feb 2012 11:21:04 -0800 > Currently all paths passed to of_find_node_by_path() must begin with a > '/', indicating a full path to the desired node. > > Augment the look-up code so that if a path does *not* begin with '/', > the path is used as the name of an /aliases property. The value of > this alias is then used as the full node path to be found. > > Signed-off-by: David Daney But as the caller you sure as hell know whether you have a "/" prefixed name or not. Why complicate an incredibly well designed and simple function for something you can create another interface for? ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Only compile OF_DYNAMIC on PowerPC pseries and iseries
From: Grant Likely Date: Tue, 14 Feb 2012 10:25:30 -0700 > Only two architectures use the OF node reference counting and reclaim bits. > There is no need to compile it for the rest of the PowerPC platforms or for > any of the other architectures. This patch makes iseries and pseries > select CONFIG_OF_DYNAMIC, and makes it default to off for everything else. > > It is still safe to turn on CONFIG_OF_DYNAMIC on all architectures, it just > isn't necessary. > > Signed-off-by: Grant Likely Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/pdt: fix section mismatch warning
From: Rob Herring Date: Tue, 27 Dec 2011 16:54:07 -0600 > On 12/27/2011 04:29 PM, David Miller wrote: >> From: Sam Ravnborg >> Date: Tue, 27 Dec 2011 23:26:58 +0100 >> >>> We have two implementations of kernel_tree_alloc() - one in fdt.c and >>> another in pdt.c. >>> >>> $ grep kernel_tree_alloc * >>> fdt.c:static void *kernel_tree_alloc(u64 size, u64 align) >>> fdt.c: __unflatten_device_tree(device_tree, mynodes, &kernel_tree_alloc); >>> pdt.c:static void * __init kernel_tree_alloc(u64 size, u64 align) >>> pdt.c: of_alias_scan(kernel_tree_alloc); >>> >>> The version in fdt.c is using kzalloc() whereas the version in pdt.c >>> uses prom_early_alloc(). >>> >>> And of_fdt_unflatten_tree() uses the version in fdt.c - so the patch is OK. >>> >>> It is confusing that they have the same name - but I did nto fix that. >>> And I forgot about this detail when I wrote the changelog. >> >> Ok, I hadn't realized this, thanks for explaining. >> >> I think Grant should apply your patch then: >> >> Acked-by: David S. Miller >> ___ > > I've applied it for 3.3 unless you think it needs to go into 3.2. It's not so critical for 3.2, thus targetting 3.3 is fine. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/pdt: fix section mismatch warning
From: Sam Ravnborg Date: Tue, 27 Dec 2011 23:26:58 +0100 > We have two implementations of kernel_tree_alloc() - one in fdt.c and > another in pdt.c. > > $ grep kernel_tree_alloc * > fdt.c:static void *kernel_tree_alloc(u64 size, u64 align) > fdt.c: __unflatten_device_tree(device_tree, mynodes, &kernel_tree_alloc); > pdt.c:static void * __init kernel_tree_alloc(u64 size, u64 align) > pdt.c: of_alias_scan(kernel_tree_alloc); > > The version in fdt.c is using kzalloc() whereas the version in pdt.c > uses prom_early_alloc(). > > And of_fdt_unflatten_tree() uses the version in fdt.c - so the patch is OK. > > It is confusing that they have the same name - but I did nto fix that. > And I forgot about this detail when I wrote the changelog. Ok, I hadn't realized this, thanks for explaining. I think Grant should apply your patch then: Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of/pdt: fix section mismatch warning
From: Sam Ravnborg Date: Tue, 27 Dec 2011 23:04:08 +0100 > prom_early_alloc() is annotated __init, and users of > kernel_tree_alloc() is also annotated __init. > So simply match the annoation of these to fix the warning. Not exactly. drivers/of/fdt.c:of_fdt_unflatten_tree() is not marked __init but does pass kernel_tree_alloc in as a callback to __unflatten_device_tree() So I don't think we can't just mark kernel_tree_alloc as __init to fix this problem. of_fdt_unflatten_tree() seems to be invokable at arbitrary points in time, even long after we boot up, so I think we'll end up having to unravel things to other way, removing the __init tag from the various implementations of prom_early_alloc(). ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: pata_of_platform.c cannot build on sparc
From: Rob Herring Date: Wed, 21 Dec 2011 17:25:15 -0600 > On 12/21/2011 04:38 PM, David Miller wrote: >> >> It depends upon CONFIG_OF_IRQ which not all CONFIG_OF platforms support, >> in particular sparc does not support CONFIG_OF_PLATFORM because it >> precomputes all IRQs at boot time when it scans the device tree so all >> of the CONFIG_OF_IRQ infrastructure to probe and resolve IRQs at driver >> probe time is wrong and completely unnecessary. >> >> Add the proper dependencies so that pata_of_platform.c doesn't get >> built on sparc. >> >> CONFIG_OF_IRQ was severely misdesigned, it should just NOP out on >> platforms where the architecture has the final IRQ values already like >> sparc does. But that's not how it was implemented at all, and now >> we're starting to have all of these drivers get hard dependencies on >> this mechanism and it's datastructures, and the resulting sparc build >> failures from time to time. >> >> Jeff, please push something like the following to Linus so that >> sparc's allmodconfig builds again. Thanks. >> > > Really, drivers should no longer use of_irq_to_resource (or > of_address_to_resource for that matter). The resources are setup by the > core OF code. The patch I sent does this. Thanks for taking care of this. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
pata_of_platform.c cannot build on sparc
It depends upon CONFIG_OF_IRQ which not all CONFIG_OF platforms support, in particular sparc does not support CONFIG_OF_PLATFORM because it precomputes all IRQs at boot time when it scans the device tree so all of the CONFIG_OF_IRQ infrastructure to probe and resolve IRQs at driver probe time is wrong and completely unnecessary. Add the proper dependencies so that pata_of_platform.c doesn't get built on sparc. CONFIG_OF_IRQ was severely misdesigned, it should just NOP out on platforms where the architecture has the final IRQ values already like sparc does. But that's not how it was implemented at all, and now we're starting to have all of these drivers get hard dependencies on this mechanism and it's datastructures, and the resulting sparc build failures from time to time. Jeff, please push something like the following to Linus so that sparc's allmodconfig builds again. Thanks. pata_of_platform: Add missing CONFIG_OF_IRQ dependency. Signed-off-by: David S. Miller diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 6bdedd7..cf047c4 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -820,7 +820,7 @@ config PATA_PLATFORM config PATA_OF_PLATFORM tristate "OpenFirmware platform device PATA support" - depends on PATA_PLATFORM && OF + depends on PATA_PLATFORM && OF && OF_IRQ help This option enables support for generic directly connected ATA devices commonly found on embedded systems with OpenFirmware ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/4] net: ethernet: xilinx: Don't use NO_IRQ in xilinx
From: Michal Simek Date: Wed, 21 Dec 2011 15:32:10 +0100 > Fix ll_temac and emaclite drivers. Only Microblaze and Xilinx PPC > use then and both use NO_IRQ as 0. It will be removed in near future. > > Signed-off-by: Michal Simek Applied, thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 1/2] net/macb: add DT support for Cadence macb/gem driver
From: Nicolas Ferre Date: Mon, 5 Dec 2011 12:59:52 +0100 > From: Jean-Christophe PLAGNIOL-VILLARD > > Allow the device tree to provide the mac address and the phy mode. > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > [nicolas.fe...@atmel.com: change "compatible" node property, doc and DT > hwaddr] > Signed-off-by: Nicolas Ferre > [ja...@jamieiles.com: add "gem" compatibility strings and doc] > Acked-by: Jamie Iles Acked-by: David S. Miller ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH net-next v6 4/4] powerpc: tqm8548/tqm8xx: add and update CAN device nodes
From: Benjamin Herrenschmidt Date: Wed, 07 Dec 2011 18:34:28 +1100 > Let me know if I should just remove them from powerpc patchwork. These are DT entries for CAN devices for which drivers only exist in the net-next tree, I already included this patch into the net-next tree so you do not have to. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] net/macb: add DT support
From: Nicolas Ferre Date: Fri, 2 Dec 2011 18:43:02 +0100 > From: Jean-Christophe PLAGNIOL-VILLARD > > Allow the device tree to provide the mac address and the phy mode. > > Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD > [nicolas.fe...@atmel.com: change "compatible" node property, doc and DT > hwaddr] > Signed-off-by: Nicolas Ferre > Cc: Jamie Iles > --- > v2: modify macb_get_hwaddr_dt() parameter You'll have to respin these two macb patches, as they don't apply properly to the net-next tree which is where they should be targetted. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4] net: add calxeda xgmac ethernet driver
From: Rob Herring Date: Tue, 22 Nov 2011 21:18:19 -0600 > From: Rob Herring > > Add support for the XGMAC 10Gb ethernet device in the Calxeda Highbank > SOC. > > Signed-off-by: Rob Herring Applied. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
