* Re: [PATCH 2/4] C/R: Basic support for network namespaces and devices (v3)
From: Serge E. Hallyn @ 2010-02-10 20:30 UTC (permalink / raw)
To: Oren Laadan; +Cc: Dan Smith, containers, netdev
In-Reply-To: <4B7310AA.3090708@cs.columbia.edu>
Quoting Oren Laadan (orenl@cs.columbia.edu):
>
>
> Dan Smith wrote:
> >SH> What exactly is this == 0 case? Does it mean 'use inherited
> >SH> netns'?
> >
> >It means it wasn't in the checkpoint image to begin with, so yeah,
> >kinda.
>
> Maybe it's time to define CKPT_OBJREF_NULL for that ?
> (to make it easy to fold, in a separate patch please)
Honestly that wouldn't be any more helpful. Just a comment. The
problem is with 0 having a different meaning for each type of
object, so 0 or CKPT_OBJREF_NULL is equally unhelpful imo :)
/* wasn't in the checkpoint image, use the netns of restarting task */
or somesuch
-serge
^ permalink raw reply
* Re: [PATCH 00/13] net: simplify seq_file code, revised
From: David Miller @ 2010-02-10 20:29 UTC (permalink / raw)
To: lizf; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <20100210.113115.28754681.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Wed, 10 Feb 2010 11:31:15 -0800 (PST)
> From: Li Zefan <lizf@cn.fujitsu.com>
> Date: Tue, 09 Feb 2010 17:18:01 +0800
>
>> This patchset introduces seq_hlist_foo() helpers, and convert
>> net/* to seq_hlist_foo() and seq_list_foo().
>>
>> Changelog:
>>
>> - Add kerneldoc in patch 1/13
>> - Fix compile warning in patch 11/13
>> - Fix a bug in patch 12/13
>
> All applied to net-next-2.6, thanks!
You did not build test your changes.
net/irda/irlan/irlan_common.c:1156: error: 'struct irlan_cb' has no member named 'list'
net/irda/irlan/irlan_common.c:1156: warning: type defaults to 'int' in declaration of '__mptr'
net/irda/irlan/irlan_common.c:1156: error: 'struct irlan_cb' has no member named 'list'
I'll fix this, but I will not next time. Instead, I'll revert all of
your changes and push it back to you.
Thanks.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-10
From: David Miller @ 2010-02-10 20:25 UTC (permalink / raw)
To: linville; +Cc: johannes, linux-wireless, netdev, linux-kernel, mb
In-Reply-To: <20100210201953.GC3286@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 10 Feb 2010 15:19:54 -0500
> On Wed, Feb 10, 2010 at 11:36:58AM -0800, David Miller wrote:
>> From: Johannes Berg <johannes@sipsolutions.net>
>> Date: Wed, 10 Feb 2010 20:15:37 +0100
>>
>> > It was intentional -- that sdev doesn't even have an irq member, but
>> > nobody ever noticed because of the wrong ifdef.
>>
>> Ok, then this needs to be explained in the commit message.
>
> OK...mind if I just revert the current version and ask Michael to
> resubmit with an appropriate changelog entry?
Have you pulled this tree into others already? Why not
just pop out the commit and fix it's commit message, then
reapply?
Having the revert commit in there is really stupid just for this.
^ permalink raw reply
* Re: [PATCH 2/4] C/R: Basic support for network namespaces and devices (v3)
From: Serge E. Hallyn @ 2010-02-10 20:25 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev
In-Reply-To: <87hbpohor5.fsf@caffeine.danplanet.com>
Quoting Dan Smith (danms@us.ibm.com):
> SH> rw_lockt is effectively a spinlock, so I don't think you can sleep
> SH> here.
>
> Yep, thanks.
>
> >> + for_each_netdev(net, dev) {
> >> + if (!dev->netdev_ops->ndo_checkpoint)
> >> + continue;
>
> SH> Won't the checkpoint_obj() call checkpoint_netdev(), which will return
> SH> -EINVAL if ndo_checkpoint is not defined?
>
> Yes, but this isn't the only place that checkpoint_netdev() could be
> called (dev->peer in the veth example) so I figured that it would be
> best to test it there too before I blindly call a NULL function
> pointer. It should never happen, but seemed prudent.
>
> SH> But here you skip the checkpoint_obj() call (which seems wrong to
> SH> me). Which do you want to have happen?
>
> What the code is doing is "skipping any interfaces in a netns that
> don't have a checkpoint operation" but would fail if you called
> checkpoint_obj() on a veth peer that happened to be missing that
> operation for some reason.
>
> I suppose you could argue that we should fail in the netns case
> instead, which will make this a bit messier for things we get for
> "free" in a new netns, like sit0. If preferable, I can just add an
> ndo_checkpoint() to sit0 as well and simply checkpoint the presence of
> it until later when we decide if we care about it.
I think that's be better. Right now if we checkpoint a container with
macvlan restart will be bogus, right? We're trying to avoid any cases
where we can't tell, at checkpoint, that restart won't be right.
> SH> By hard-coding veth stuff into generic-sounding functions in
> SH> net/checkpoint_dev.c you seem to be assuming that only veth will
> SH> ever be supported for checkpoint/restart? what about macvlan?
> SH> (Not to mention that eventually we intend to support moving
> SH> physical nics into containers)
>
> No, that's not what I'm assuming. The only interface type I need to
> control with RTNL is veth right now. So, if you'd prefer a
> single-case of:
>
> if (type == veth)
> do_veth_message();
> else
> fail();
>
> to record the goal of having more types later I'll happily add that
> unreachable code to the patch :)
What I was asking is should do_veth_message() be in drivers/net/veth.c?
-serge
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-10
From: John W. Linville @ 2010-02-10 20:19 UTC (permalink / raw)
To: David Miller; +Cc: johannes, linux-wireless, netdev, linux-kernel, mb
In-Reply-To: <20100210.113658.137273026.davem@davemloft.net>
On Wed, Feb 10, 2010 at 11:36:58AM -0800, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Wed, 10 Feb 2010 20:15:37 +0100
>
> > It was intentional -- that sdev doesn't even have an irq member, but
> > nobody ever noticed because of the wrong ifdef.
>
> Ok, then this needs to be explained in the commit message.
OK...mind if I just revert the current version and ask Michael to
resubmit with an appropriate changelog entry?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 2/4] C/R: Basic support for network namespaces and devices (v3)
From: Oren Laadan @ 2010-02-10 20:01 UTC (permalink / raw)
To: Dan Smith
Cc: containers-qjLDD68F18O7TbgM5vRIOg, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87pr4dgfdz.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
Dan Smith wrote:
> SH> What exactly is this == 0 case? Does it mean 'use inherited
> SH> netns'?
>
> It means it wasn't in the checkpoint image to begin with, so yeah,
> kinda.
Maybe it's time to define CKPT_OBJREF_NULL for that ?
(to make it easy to fold, in a separate patch please)
Oren.
>
> SH> Don't you then still need to
>
> SH> get_net(current->nsproxy->net_ns);
> SH> nsproxy-> net_ns = current->nsproxy->net_ns;
>
> Yes, I'll unify that path a bit. Thanks.
>
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Grant Likely @ 2010-02-10 19:57 UTC (permalink / raw)
To: Andy Fleming; +Cc: John Linn, devicetree-discuss, netdev, Scott Wood
In-Reply-To: <99A0D59F-3DAA-4ACD-899B-7D139E286D6D@freescale.com>
On Wed, Feb 10, 2010 at 12:46 PM, Andy Fleming <afleming@freescale.com> wrote:
>
> On Feb 10, 2010, at 1:20 PM, Grant Likely wrote:
>
>> On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
>> <afleming@freescale.com> wrote:
>>> I don't think it's necessary that only one phy node is there. I don't think
>>> the of mdio layer should set policy, here. Some drivers hard code their
>>> addresses. Some drivers assume (foolishly, I think) that the PHYs are in
>>> order. Many assume there's only one PHY. I think the mdio driver should
>>> set policy, so of_mdio should just allow for PHYs to be probed. I'm
>>> actually not sure that requires any changes. Quite possibly this just means
>>> that of_mdio is not appropriate for such a driver. The standard PHY code
>>> supports this sort of thing.
>>
>> That still doesn't solve the problem of matching PHYs to MACs.
>>
>> Consider this example: 2 MACs, 2 PHYs. mac_a--> phy_a and mac_b -->
>> phy_b. Both phys on the same mdio bus, described thus:
>>
>> eth_a: ethernet@81000000 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> phy-handle = <&phy_a>;
>> mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> phy_a: phy_a {
>> } ;
>> phy_b: phy_b {
>> } ;
>> } ;
>> } ;
>> eth_b: ethernet@82000000 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> phy-handle = <&phy_b>;
>> } ;
>>
>> In this example, the kernel knows it has two phys, and probing
>> confirms this (say at phy addresses 3 and 7). How does the kernel
>> know which address phy_a responds to?
>
>
> There's no way to know.
Which is why I'm saying that when the phy address is unknown, the
binding should only allow for a single phy node. We're talking about
how to accurately describe the platform, not how the implementation
should work. The mdio/of_mdio changes are Linux kernel implementation
details.
> That's what I'm saying. We shouldn't modify the of_mdio code to say which PHY is which. Instead, we have the MDIO/ethernet code do that. And maybe this means that they can't use of_mdio. Or maybe we need to devise a scheme so you can specify those PHYs, but delay associating them with an address until later.
Same problem. even if phys are probed, the kernel doesn't know which
MAC to attach each to. If the solution is to hard coded it into the
driver, then that is a different problem scenario than John is trying
to solve.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Andy Fleming @ 2010-02-10 19:46 UTC (permalink / raw)
To: Grant Likely; +Cc: John Linn, devicetree-discuss, netdev, Scott Wood
In-Reply-To: <fa686aa41002101120v56ef5e7cm64e5505cc7bedc1d@mail.gmail.com>
On Feb 10, 2010, at 1:20 PM, Grant Likely wrote:
> On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
> <afleming@freescale.com> wrote:
>>
>>
>> On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca> wrote:
>>
>>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>>>>>
>>>>> -----Original Message-----
>>>>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
>>>>> Grant Likely
>>>>> Sent: Wednesday, February 10, 2010 9:44 AM
>>>>> To: John Linn; devicetree-discuss; netdev
>>>>> Subject: Re: phy address in the device tree, vs auto probing
>>>>>
>>>>> (cc'ing devicetree-discuss and netdev mailing lists)
>>>>>
>>>>> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@xilinx.com> wrote:
>>>>>>
>>>>>> Hi Grant,
>>>>>>
>>>>>> I notice that the OF driver for the mdio bus is not doing auto probing.
>>>>>>
>>>>>> As we start putting in the phy layer in the emac drivers, the device
>>>>>> trees tend to have the phy address in them, but we're not sure we
>>>>>> really
>>>>>> like that.
>>>>>>
>>>>>> We really think that being able to let the kernel find the phy address
>>>>>> is a big benefit, otherwise this is one other piece of info the user
>>>>>> has
>>>>>> to know and get right.
>>>>>>
>>>>>> Am I missing something here?
>>>>>
>>>>> No, you're not really missing something, but there is an inherent
>>>>> complexity in what you're wanting to do. Like i2c, MDIO is one of
>>>>> those busses that is hard to probe reliable. Some PHYs respond on
>>>>> more than one address, and there is no way to determine which MAC a
>>>>> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs
>>>>> with their own MDIO busses may still get wired to a PHY on a different
>>>>> bus.
>>>>>
>>>>> In the simple case where there is a one:one:one relationship between
>>>>> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>>>> correct? The question then must be asked; how does the kernel
>>>>> determine that it can use the simple case? Nobody has yet defined a
>>>>> way to describe that in the device tree; mostly because nobody has
>>>>> needed to yet.
>>>>>
>>>>> So, it is possible to do what you want, but you need a way to
>>>>> *explicitly* ask for that behaviour. ie, some way to indicate in a
>>>>> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>>>> probed for. I think this should only be an option when the MDIO bus
>>>>> has only one PHY. Come up with a proposal and post it to the
>>>>> devicetree-discuss mailing list.
>>>>
>>>> Here's a couple ideas. See what everyone thinks as I'm not stuck on
>>>> either.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> 1. What if we just don't specific a phy address with a reg property which
>>>> would specify to auto probe it and find the phy as illustrated below?
>>>>
>>>>
>>>> Ethernet_MAC: ethernet@81000000 {
>>>> #address-cells = <1>;
>>>> #size-cells = <1>;
>>>> phy-handle = <&phy0>;
>>>> mdio {
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>> phy0: phy@7 {
>>>> } ;
>>>> } ;
>>>>
>>>> 2. Or a special value (-1 or something not 0 - 31) in the phy address
>>>> that specifies to auto probe as illustrated below.
>>>> phy0: phy@7 {
>>>> reg = <-1>;
>>>> } ;
>>>
>>> I don't like abusing the reg property in this way. I wonder if a new
>>> empty property would be a better way to indicate this. Maybe
>>> "phy-probe-address;"? It would also be important to specify in the
>>> binding that only one phy node is allowed when phy-probe-address is
>>> used.
>>
>> I don't think it's necessary that only one phy node is there. I don't think
>> the of mdio layer should set policy, here. Some drivers hard code their
>> addresses. Some drivers assume (foolishly, I think) that the PHYs are in
>> order. Many assume there's only one PHY. I think the mdio driver should
>> set policy, so of_mdio should just allow for PHYs to be probed. I'm
>> actually not sure that requires any changes. Quite possibly this just means
>> that of_mdio is not appropriate for such a driver. The standard PHY code
>> supports this sort of thing.
>
> That still doesn't solve the problem of matching PHYs to MACs.
>
> Consider this example: 2 MACs, 2 PHYs. mac_a--> phy_a and mac_b -->
> phy_b. Both phys on the same mdio bus, described thus:
>
> eth_a: ethernet@81000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> phy-handle = <&phy_a>;
> mdio {
> #address-cells = <1>;
> #size-cells = <0>;
> phy_a: phy_a {
> } ;
> phy_b: phy_b {
> } ;
> } ;
> } ;
> eth_b: ethernet@82000000 {
> #address-cells = <1>;
> #size-cells = <1>;
> phy-handle = <&phy_b>;
> } ;
>
> In this example, the kernel knows it has two phys, and probing
> confirms this (say at phy addresses 3 and 7). How does the kernel
> know which address phy_a responds to?
There's no way to know. That's what I'm saying. We shouldn't modify the of_mdio code to say which PHY is which. Instead, we have the MDIO/ethernet code do that. And maybe this means that they can't use of_mdio. Or maybe we need to devise a scheme so you can specify those PHYs, but delay associating them with an address until later.
Andy
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-10
From: David Miller @ 2010-02-10 19:36 UTC (permalink / raw)
To: johannes; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <1265829337.19075.0.camel@jlt3.sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 10 Feb 2010 20:15:37 +0100
> It was intentional -- that sdev doesn't even have an irq member, but
> nobody ever noticed because of the wrong ifdef.
Ok, then this needs to be explained in the commit message.
^ permalink raw reply
* Re: [PATCH 00/13] net: simplify seq_file code, revised
From: David Miller @ 2010-02-10 19:31 UTC (permalink / raw)
To: lizf; +Cc: akpm, linux-kernel, netdev
In-Reply-To: <4B712849.9040400@cn.fujitsu.com>
From: Li Zefan <lizf@cn.fujitsu.com>
Date: Tue, 09 Feb 2010 17:18:01 +0800
> This patchset introduces seq_hlist_foo() helpers, and convert
> net/* to seq_hlist_foo() and seq_list_foo().
>
> Changelog:
>
> - Add kerneldoc in patch 1/13
> - Fix compile warning in patch 11/13
> - Fix a bug in patch 12/13
All applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [PATCH 2/4] C/R: Basic support for network namespaces and devices (v3)
From: Dan Smith @ 2010-02-10 19:30 UTC (permalink / raw)
To: Serge E. Hallyn; +Cc: containers, netdev
In-Reply-To: <20100210192019.GA18879@us.ibm.com>
SH> rw_lockt is effectively a spinlock, so I don't think you can sleep
SH> here.
Yep, thanks.
>> + for_each_netdev(net, dev) {
>> + if (!dev->netdev_ops->ndo_checkpoint)
>> + continue;
SH> Won't the checkpoint_obj() call checkpoint_netdev(), which will return
SH> -EINVAL if ndo_checkpoint is not defined?
Yes, but this isn't the only place that checkpoint_netdev() could be
called (dev->peer in the veth example) so I figured that it would be
best to test it there too before I blindly call a NULL function
pointer. It should never happen, but seemed prudent.
SH> But here you skip the checkpoint_obj() call (which seems wrong to
SH> me). Which do you want to have happen?
What the code is doing is "skipping any interfaces in a netns that
don't have a checkpoint operation" but would fail if you called
checkpoint_obj() on a veth peer that happened to be missing that
operation for some reason.
I suppose you could argue that we should fail in the netns case
instead, which will make this a bit messier for things we get for
"free" in a new netns, like sit0. If preferable, I can just add an
ndo_checkpoint() to sit0 as well and simply checkpoint the presence of
it until later when we decide if we care about it.
SH> By hard-coding veth stuff into generic-sounding functions in
SH> net/checkpoint_dev.c you seem to be assuming that only veth will
SH> ever be supported for checkpoint/restart? what about macvlan?
SH> (Not to mention that eventually we intend to support moving
SH> physical nics into containers)
No, that's not what I'm assuming. The only interface type I need to
control with RTNL is veth right now. So, if you'd prefer a
single-case of:
if (type == veth)
do_veth_message();
else
fail();
to record the goal of having more types later I'll happily add that
unreachable code to the patch :)
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Mark Brown @ 2010-02-10 19:24 UTC (permalink / raw)
To: Grant Likely
Cc: M. Warner Losh, scottwood, netdev, devicetree-discuss, afleming
In-Reply-To: <fa686aa41002101112o66a74f60jc65fdffb48fd7213@mail.gmail.com>
On Wed, Feb 10, 2010 at 12:12:14PM -0700, Grant Likely wrote:
> On Wed, Feb 10, 2010 at 11:37 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> > There are times that you'd want a list of PHY addresses to use. ?This
> > suggests a bitmask, but I don't know if they are common enough to
> > warrant the extra burden on the usual case...
> Are you talking a single MAC attached to multiple PHYs? If so, then
> the current device tree binding doesn't support this, but it would be
> easy to extend the current binding by making the phy-handle property a
> list of phy nodes phandes.
There's also the entertaining case I've dealt with (pre device tree but
actually on PowerPC) where the MAC has multiple PHYs attached but they
should only be exposed to userspace and the driver should rely on MII
configuration provided by userspace without touching them.
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Grant Likely @ 2010-02-10 19:20 UTC (permalink / raw)
To: Fleming Andy-AFLEMING; +Cc: John Linn, devicetree-discuss, netdev, Scott Wood
In-Reply-To: <AE7D03BA-0763-42F3-A27B-A6214CE7249E@freescale.com>
On Wed, Feb 10, 2010 at 11:40 AM, Fleming Andy-AFLEMING
<afleming@freescale.com> wrote:
>
>
> On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>>>>
>>>> -----Original Message-----
>>>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of
>>>> Grant Likely
>>>> Sent: Wednesday, February 10, 2010 9:44 AM
>>>> To: John Linn; devicetree-discuss; netdev
>>>> Subject: Re: phy address in the device tree, vs auto probing
>>>>
>>>> (cc'ing devicetree-discuss and netdev mailing lists)
>>>>
>>>> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@xilinx.com> wrote:
>>>>>
>>>>> Hi Grant,
>>>>>
>>>>> I notice that the OF driver for the mdio bus is not doing auto probing.
>>>>>
>>>>> As we start putting in the phy layer in the emac drivers, the device
>>>>> trees tend to have the phy address in them, but we're not sure we
>>>>> really
>>>>> like that.
>>>>>
>>>>> We really think that being able to let the kernel find the phy address
>>>>> is a big benefit, otherwise this is one other piece of info the user
>>>>> has
>>>>> to know and get right.
>>>>>
>>>>> Am I missing something here?
>>>>
>>>> No, you're not really missing something, but there is an inherent
>>>> complexity in what you're wanting to do. Like i2c, MDIO is one of
>>>> those busses that is hard to probe reliable. Some PHYs respond on
>>>> more than one address, and there is no way to determine which MAC a
>>>> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs
>>>> with their own MDIO busses may still get wired to a PHY on a different
>>>> bus.
>>>>
>>>> In the simple case where there is a one:one:one relationship between
>>>> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>>> correct? The question then must be asked; how does the kernel
>>>> determine that it can use the simple case? Nobody has yet defined a
>>>> way to describe that in the device tree; mostly because nobody has
>>>> needed to yet.
>>>>
>>>> So, it is possible to do what you want, but you need a way to
>>>> *explicitly* ask for that behaviour. ie, some way to indicate in a
>>>> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>>> probed for. I think this should only be an option when the MDIO bus
>>>> has only one PHY. Come up with a proposal and post it to the
>>>> devicetree-discuss mailing list.
>>>
>>> Here's a couple ideas. See what everyone thinks as I'm not stuck on
>>> either.
>>>
>>> Thanks,
>>> John
>>>
>>> 1. What if we just don't specific a phy address with a reg property which
>>> would specify to auto probe it and find the phy as illustrated below?
>>>
>>>
>>> Ethernet_MAC: ethernet@81000000 {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> phy-handle = <&phy0>;
>>> mdio {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>> phy0: phy@7 {
>>> } ;
>>> } ;
>>>
>>> 2. Or a special value (-1 or something not 0 - 31) in the phy address
>>> that specifies to auto probe as illustrated below.
>>> phy0: phy@7 {
>>> reg = <-1>;
>>> } ;
>>
>> I don't like abusing the reg property in this way. I wonder if a new
>> empty property would be a better way to indicate this. Maybe
>> "phy-probe-address;"? It would also be important to specify in the
>> binding that only one phy node is allowed when phy-probe-address is
>> used.
>
> I don't think it's necessary that only one phy node is there. I don't think
> the of mdio layer should set policy, here. Some drivers hard code their
> addresses. Some drivers assume (foolishly, I think) that the PHYs are in
> order. Many assume there's only one PHY. I think the mdio driver should
> set policy, so of_mdio should just allow for PHYs to be probed. I'm
> actually not sure that requires any changes. Quite possibly this just means
> that of_mdio is not appropriate for such a driver. The standard PHY code
> supports this sort of thing.
That still doesn't solve the problem of matching PHYs to MACs.
Consider this example: 2 MACs, 2 PHYs. mac_a--> phy_a and mac_b -->
phy_b. Both phys on the same mdio bus, described thus:
eth_a: ethernet@81000000 {
#address-cells = <1>;
#size-cells = <1>;
phy-handle = <&phy_a>;
mdio {
#address-cells = <1>;
#size-cells = <0>;
phy_a: phy_a {
} ;
phy_b: phy_b {
} ;
} ;
} ;
eth_b: ethernet@82000000 {
#address-cells = <1>;
#size-cells = <1>;
phy-handle = <&phy_b>;
} ;
In this example, the kernel knows it has two phys, and probing
confirms this (say at phy addresses 3 and 7). How does the kernel
know which address phy_a responds to?
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/4] C/R: Basic support for network namespaces and devices (v3)
From: Serge E. Hallyn @ 2010-02-10 19:20 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev
In-Reply-To: <87ljf1gemh.fsf@caffeine.danplanet.com>
Quoting Dan Smith (danms@us.ibm.com):
> Guilt dropped the new checkpoint_dev.c file when I switched to the
> newer branch. Sorry about that. Updated patch included below.
(Just a few comments on a cursory look. Will take a closer look
later)
> +int ckpt_netdev_inet_addrs(struct in_device *indev,
> + struct ckpt_netdev_addr *_abuf[])
> +{
> + struct ckpt_netdev_addr *abuf = NULL;
> + struct in_ifaddr *addr = indev->ifa_list;
> + int pages = 0;
> + int addrs = 0;
> + int max;
> +
> + read_lock(&dev_base_lock);
> + retry:
> + if (++pages > 4) {
> + addrs = -ENOMEM;
> + goto out;
> + }
> +
> + *_abuf = krealloc(abuf, PAGE_SIZE * pages, GFP_KERNEL);
rw_lockt is effectively a spinlock, so I don't think you can sleep
here.
> + if (*_abuf == NULL) {
> + addrs = -ENOMEM;
> + goto out;
> + }
> + abuf = *_abuf;
> +
> + max = (pages * PAGE_SIZE) / sizeof(*abuf);
> + while (addr) {
> + abuf[addrs].type = CKPT_NETDEV_ADDR_IPV4; /* Only IPv4 now */
> + abuf[addrs].inet4_local = addr->ifa_local;
> + abuf[addrs].inet4_address = addr->ifa_address;
> + abuf[addrs].inet4_mask = addr->ifa_mask;
> + abuf[addrs].inet4_broadcast = addr->ifa_broadcast;
> +
> + addr = addr->ifa_next;
> + if (++addrs >= max)
> + goto retry;
> + }
> +
> + out:
> + read_unlock(&dev_base_lock);
> +
> + if (addrs < 0) {
> + kfree(abuf);
> + *_abuf = NULL;
> + }
> +
> + return addrs;
> +}
> +
> +struct ckpt_hdr_netdev *ckpt_netdev_base(struct ckpt_ctx *ctx,
> + struct net_device *dev,
> + struct ckpt_netdev_addr *addrs[])
> +{
> + struct ckpt_hdr_netdev *h;
> + int ret;
> +
> + h = ckpt_hdr_get_type(ctx, sizeof(*h), CKPT_HDR_NETDEV);
> + if (!h)
> + return ERR_PTR(-ENOMEM);
> +
> + ret = ckpt_netdev_hwaddr(dev, h);
> + if (ret < 0)
> + goto out;
> +
> + *addrs = NULL;
> + ret = h->inet_addrs = ckpt_netdev_inet_addrs(dev->ip_ptr, addrs);
> + if (ret < 0)
> + goto out;
> +
> + ret = h->netns_ref = checkpoint_obj(ctx, dev->nd_net, CKPT_OBJ_NET_NS);
> + out:
> + if (ret < 0) {
> + ckpt_hdr_put(ctx, h);
> + h = ERR_PTR(ret);
> + if (*addrs)
> + kfree(*addrs);
> + }
> +
> + return h;
> +}
> +
> +int checkpoint_netdev(struct ckpt_ctx *ctx, void *ptr)
> +{
> + struct net_device *dev = (struct net_device *)ptr;
> +
> + if (!dev->netdev_ops->ndo_checkpoint)
> + return -EINVAL;
> +
> + ckpt_debug("checkpointing netdev %s\n", dev->name);
> +
> + return dev->netdev_ops->ndo_checkpoint(ctx, dev);
> +}
> +
> +int checkpoint_netns(struct ckpt_ctx *ctx, void *ptr)
> +{
> + struct net *net = ptr;
> + struct net_device *dev;
> + struct ckpt_hdr_netns *h;
> + int ret;
> +
> + h = ckpt_hdr_get_type(ctx, sizeof(*h), CKPT_HDR_NET_NS);
> + if (!h)
> + return -ENOMEM;
> +
> + h->this_ref = ckpt_obj_lookup(ctx, net, CKPT_OBJ_NET_NS);
> + BUG_ON(h->this_ref == 0);
> +
> + ret = ckpt_write_obj(ctx, (struct ckpt_hdr *) h);
> + if (ret < 0)
> + goto out;
> +
> + for_each_netdev(net, dev) {
> + if (!dev->netdev_ops->ndo_checkpoint)
> + continue;
Won't the checkpoint_obj() call checkpoint_netdev(), which will return
-EINVAL if ndo_checkpoint is not defined? But here you skip the
checkpoint_obj() call (which seems wrong to me). Which do you want to
have happen?
> + ret = checkpoint_obj(ctx, dev, CKPT_OBJ_NETDEV);
> + if (ret < 0)
> + break;
> + }
> + out:
> + ckpt_hdr_put(ctx, h);
> +
> + return ret;
> +}
> +
> +static int restore_in_addrs(struct ckpt_ctx *ctx,
> + __u32 naddrs,
> + struct net *net,
> + struct net_device *dev)
> +{
> + __u32 i;
> + int ret = 0;
> + int len = naddrs * sizeof(struct ckpt_netdev_addr);
> + struct ckpt_netdev_addr *addrs = NULL;
> +
> + addrs = kmalloc(len, GFP_KERNEL);
> + if (!addrs)
> + return -ENOMEM;
> +
> + ret = _ckpt_read_buffer(ctx, addrs, len);
> + if (ret < 0)
> + goto out;
> +
> + for (i = 0; i < naddrs; i++) {
> + struct ckpt_netdev_addr *addr = &addrs[i];
> + struct ifreq req;
> + struct sockaddr_in *inaddr;
> +
> + if (addr->type != CKPT_NETDEV_ADDR_IPV4) {
> + ret = -EINVAL;
> + ckpt_err(ctx, ret, "Unsupported netdev addr type %i\n",
> + addr->type);
> + break;
> + }
> +
> + ckpt_debug("restoring %s: %x/%x/%x\n", dev->name,
> + addr->inet4_address,
> + addr->inet4_mask,
> + addr->inet4_broadcast);
> +
> + memcpy(req.ifr_name, dev->name, IFNAMSIZ);
> +
> + inaddr = (struct sockaddr_in *)&req.ifr_addr;
> + inaddr->sin_addr.s_addr = addr->inet4_address;
> + inaddr->sin_family = AF_INET;
> + ret = __kern_devinet_ioctl(net, SIOCSIFADDR, &req);
> + if (ret < 0) {
> + ckpt_err(ctx, ret, "Failed to set address\n");
> + break;
> + }
> +
> + inaddr = (struct sockaddr_in *)&req.ifr_addr;
> + inaddr->sin_addr.s_addr = addr->inet4_mask;
> + inaddr->sin_family = AF_INET;
> + ret = __kern_devinet_ioctl(net, SIOCSIFNETMASK, &req);
> + if (ret < 0) {
> + ckpt_err(ctx, ret, "Failed to set netmask\n");
> + break;
> + }
> +
> + inaddr = (struct sockaddr_in *)&req.ifr_addr;
> + inaddr->sin_addr.s_addr = addr->inet4_broadcast;
> + inaddr->sin_family = AF_INET;
> + ret = __kern_devinet_ioctl(net, SIOCSIFBRDADDR, &req);
> + if (ret < 0) {
> + ckpt_err(ctx, ret, "Failed to set broadcast\n");
> + break;
> + }
> + }
> +
> + out:
> + kfree(addrs);
> +
> + return ret;
> +}
> +
> +static int veth_peer_data(struct sk_buff *skb, char *peer_name)
> +{
> + struct nlattr *linkdata;
> + struct ifinfomsg ifm;
> +
> + linkdata = nla_nest_start(skb, IFLA_INFO_DATA);
> + if (!linkdata)
> + return -ENOMEM;
> +
> + nla_put(skb, VETH_INFO_PEER, sizeof(ifm), &ifm);
> + nla_put_string(skb, IFLA_IFNAME, peer_name);
> +
> + nla_nest_end(skb, linkdata);
> +
> + return 0;
> +}
> +
> +static struct sk_buff *new_link_message(char *this_name, char *peer_name)
> +{
> + int ret = -ENOMEM;
> + int flags = NLM_F_REQUEST | NLM_F_CREATE | NLM_F_ACK;
> + struct nlmsghdr *nlh;
> + struct sk_buff *skb;
> + struct ifinfomsg *ifm;
> + struct nlattr *linkinfo;
> +
> + skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
> + if (!skb)
> + goto out;
> +
> + nlh = nlmsg_put(skb, 0, 0, RTM_NEWLINK, sizeof(*ifm), flags);
> + if (!nlh)
> + goto out;
> +
> + ifm = nlmsg_data(nlh);
> + memset(ifm, 0, sizeof(*ifm));
> +
> + ret = nla_put_string(skb, IFLA_IFNAME, this_name);
> + if (ret)
> + goto out;
> +
> + ret = -ENOMEM;
> +
> + linkinfo = nla_nest_start(skb, IFLA_LINKINFO);
> + if (!linkinfo)
> + goto out;
> +
> + if (nla_put_string(skb, IFLA_INFO_KIND, "veth") < 0)
> + goto out;
> +
> + ret = veth_peer_data(skb, peer_name);
By hard-coding veth stuff into generic-sounding functions in
net/checkpoint_dev.c you seem to be assuming that only veth will
ever be supported for checkpoint/restart? what about macvlan?
(Not to mention that eventually we intend to support moving
physical nics into containers)
-serge
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-10
From: Johannes Berg @ 2010-02-10 19:15 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100210.110756.201335073.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
On Wed, 2010-02-10 at 11:07 -0800, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Wed, 10 Feb 2010 13:58:16 -0500
>
> > Please let me know if there are problems!
>
> I see one:
>
> > diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> > index 5681ebe..03dfd27 100644
> > --- a/drivers/ssb/main.c
> > +++ b/drivers/ssb/main.c
> > @@ -494,8 +494,7 @@ static int ssb_devices_register(struct ssb_bus
> *bus)
> > #endif
> > break;
> > case SSB_BUSTYPE_SDIO:
> > -#ifdef CONFIG_SSB_SDIO
> > - sdev->irq = bus->host_sdio->dev.irq;
> > +#ifdef CONFIG_SSB_SDIOHOST
> > dev->parent = &bus->host_sdio->dev;
> > #endif
> > break;
>
> The commit message says "fix a typo" but it's also removing
> the assignment of sdev->irq
>
> All the bus types assign the sdev->irq, so it looks like
> this was removed unintentionally.
>
> If it was intentional, it needs to be explained in the
> commit message or a code comment.
It was intentional -- that sdev doesn't even have an irq member, but
nobody ever noticed because of the wrong ifdef.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Grant Likely @ 2010-02-10 19:12 UTC (permalink / raw)
To: M. Warner Losh; +Cc: scottwood, netdev, devicetree-discuss, afleming
In-Reply-To: <20100210.113720.1026572228166328165.imp@bsdimp.com>
On Wed, Feb 10, 2010 at 11:37 AM, M. Warner Losh <imp@bsdimp.com> wrote:
> In message: <4B72FAB2.5000804@freescale.com>
> Scott Wood <scottwood@freescale.com> writes:
> : Grant Likely wrote:
> : >> 2. Or a special value (-1 or something not 0 - 31) in the phy address
> : >> that specifies to auto probe as illustrated below.
> : >> phy0: phy@7 {
> : >> reg = <-1>;
> : >> } ;
> : > I don't like abusing the reg property in this way. I wonder if a new
> : > empty property would be a better way to indicate this. Maybe
> : > "phy-probe-address;"? It would also be important to specify in the
> : > binding that only one phy node is allowed when phy-probe-address is
> : > used.
> : > Also, without a known reg the 'phy@7' name is inaccurate. Drop the
> : > @7.
> : > Scott, Andy: any thoughts?
> :
> : I'm not fond of the -1. I'd prefer the explicit phy-probe-address
> : property, though I don't mind too much using the absence of reg.
>
> There are times that you'd want a list of PHY addresses to use. This
> suggests a bitmask, but I don't know if they are common enough to
> warrant the extra burden on the usual case...
Are you talking a single MAC attached to multiple PHYs? If so, then
the current device tree binding doesn't support this, but it would be
easy to extend the current binding by making the phy-handle property a
list of phy nodes phandes.
If you're talking about a phy being able to appear at a number of
addresses, then perhaps this could be handled by simple listing the
full range of base addresses in the phy's reg property. So for a phy
that could appear at address 2, 3, 6, or 7:
reg = <2 3 6 7>;
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH][v4] tcp: fix ICMP-RTO war
From: David Miller @ 2010-02-10 19:08 UTC (permalink / raw)
To: damian; +Cc: netdev, ilpo.jarvinen
In-Reply-To: <4B7303C2.5000703@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Wed, 10 Feb 2010 20:06:42 +0100
> Make sure, that TCP has a nonzero RTT estimation after three-way
> handshake. Currently, a listening TCP has a value of 0 for srtt,
> rttvar and rto right after the three-way handshake is completed
> with TCP timestamps disabled.
> This will lead to corrupt RTO recalculation and retransmission
> flood when RTO is recalculated on backoff reversion as introduced
> in "Revert RTO on ICMP destination unreachable"
> (f1ecd5d9e7366609d640ff4040304ea197fbc618).
> This behaviour can be provoked by connecting to a server which
> "responds first" (like SMTP) and rejecting every packet after
> the handshake with dest-unreachable, which will lead to softirq
> load on the server (up to 30% per socket in some tests).
>
> Thanks to Ilpo Jarvinen for providing debug patches and to
> Denys Fedoryshchenko for reporting and testing.
>
> Changes since v3: Removed bad characters in patchfile.
>
> Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
> Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
Thanks for doing this work, I'll study these issues
and review this patch today.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-10
From: David Miller @ 2010-02-10 19:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100210185816.GB3286@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 10 Feb 2010 13:58:16 -0500
> Please let me know if there are problems!
I see one:
> diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
> index 5681ebe..03dfd27 100644
> --- a/drivers/ssb/main.c
> +++ b/drivers/ssb/main.c
> @@ -494,8 +494,7 @@ static int ssb_devices_register(struct ssb_bus *bus)
> #endif
> break;
> case SSB_BUSTYPE_SDIO:
> -#ifdef CONFIG_SSB_SDIO
> - sdev->irq = bus->host_sdio->dev.irq;
> +#ifdef CONFIG_SSB_SDIOHOST
> dev->parent = &bus->host_sdio->dev;
> #endif
> break;
The commit message says "fix a typo" but it's also removing
the assignment of sdev->irq
All the bus types assign the sdev->irq, so it looks like
this was removed unintentionally.
If it was intentional, it needs to be explained in the
commit message or a code comment.
^ permalink raw reply
* [PATCH][v4] tcp: fix ICMP-RTO war
From: Damian Lukowski @ 2010-02-10 19:06 UTC (permalink / raw)
To: Netdev; +Cc: David Miller, Ilpo Järvinen
Make sure, that TCP has a nonzero RTT estimation after three-way
handshake. Currently, a listening TCP has a value of 0 for srtt,
rttvar and rto right after the three-way handshake is completed
with TCP timestamps disabled.
This will lead to corrupt RTO recalculation and retransmission
flood when RTO is recalculated on backoff reversion as introduced
in "Revert RTO on ICMP destination unreachable"
(f1ecd5d9e7366609d640ff4040304ea197fbc618).
This behaviour can be provoked by connecting to a server which
"responds first" (like SMTP) and rejecting every packet after
the handshake with dest-unreachable, which will lead to softirq
load on the server (up to 30% per socket in some tests).
Thanks to Ilpo Jarvinen for providing debug patches and to
Denys Fedoryshchenko for reporting and testing.
Changes since v3: Removed bad characters in patchfile.
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: Damian Lukowski <damian@tvk.rwth-aachen.de>
---
net/ipv4/tcp_input.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 28e0296..da7173b 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5783,12 +5783,10 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb,
/* tcp_ack considers this ACK as duplicate
* and does not calculate rtt.
- * Fix it at least with timestamps.
+ * Force it here.
*/
- if (tp->rx_opt.saw_tstamp &&
- tp->rx_opt.rcv_tsecr && !tp->srtt)
- tcp_ack_saw_tstamp(sk, 0);
-
+ tcp_ack_update_rtt(sk, 0, 0);
+
if (tp->rx_opt.tstamp_ok)
tp->advmss -= TCPOLEN_TSTAMP_ALIGNED;
-- 1.6.4.4
^ permalink raw reply related
* pull request: wireless-2.6 2010-02-10
From: John W. Linville @ 2010-02-10 18:58 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more hopefuls for 2.6.33. Most of them are small and
obvious. The b43 one appears larger because it adds a comment, but it
makes a significant performance improvement against a long-standing
regression. The scan.c one mostly moves some code around and will save
us from a lot of WARN_ON noise. And just for good measure, we add a USB
ID to rtl8187. :-)
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 44bfce5c3ec91baf8ffcd075c66711740f29a949:
David S. Miller (1):
Merge branch 'master' of git://git.kernel.org/.../holtmann/bluetooth-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Benoit Papillault (1):
mac80211: Fix probe request filtering in IBSS mode
Jelle Martijn Kok (1):
rtl8187: Add new device ID
Johannes Berg (1):
mac80211: fix deferred hardware scan requests
Larry Finger (1):
b43: Fix throughput regression
Michael Buesch (1):
ssb: Fix CONFIG_SSB_SDIOHOST typo
Roel Kluin (1):
iwmc3200wifi: Test of wrong pointer after kzalloc in iwm_mlme_update_bss_table()
Sujith (1):
ath9k: Fix sequence numbers for PAE frames
Wey-Yi Guy (1):
iwlwifi: Fix to set correct ht configuration
drivers/net/wireless/ath/ath9k/xmit.c | 4 ++--
drivers/net/wireless/b43/b43.h | 1 +
drivers/net/wireless/b43/main.c | 13 ++++++++++---
drivers/net/wireless/iwlwifi/iwl-core.c | 1 +
drivers/net/wireless/iwmc3200wifi/rx.c | 2 +-
drivers/net/wireless/rtl818x/rtl8187_dev.c | 1 +
drivers/ssb/main.c | 3 +--
net/mac80211/ibss.c | 2 +-
net/mac80211/scan.c | 18 ++++++++++--------
9 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index fa12b90..29bf336 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1615,7 +1615,7 @@ static int ath_tx_setup_buffer(struct ieee80211_hw *hw, struct ath_buf *bf,
bf->bf_frmlen -= padsize;
}
- if (conf_is_ht(&hw->conf) && !is_pae(skb))
+ if (conf_is_ht(&hw->conf))
bf->bf_state.bf_type |= BUF_HT;
bf->bf_flags = setup_tx_flags(sc, skb, txctl->txq);
@@ -1701,7 +1701,7 @@ static void ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
goto tx_done;
}
- if (tx_info->flags & IEEE80211_TX_CTL_AMPDU) {
+ if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && !is_pae(skb)) {
/*
* Try aggregation if it's a unicast data frame
* and the destination is HT capable.
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index fe3bf94..c484cc2 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -115,6 +115,7 @@
#define B43_MMIO_TSF_2 0x636 /* core rev < 3 only */
#define B43_MMIO_TSF_3 0x638 /* core rev < 3 only */
#define B43_MMIO_RNG 0x65A
+#define B43_MMIO_IFSSLOT 0x684 /* Interframe slot time */
#define B43_MMIO_IFSCTL 0x688 /* Interframe space control */
#define B43_MMIO_IFSCTL_USE_EDCF 0x0004
#define B43_MMIO_POWERUP_DELAY 0x6A8
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 19b4eae..fcbf0e2 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -628,10 +628,17 @@ static void b43_upload_card_macaddress(struct b43_wldev *dev)
static void b43_set_slot_time(struct b43_wldev *dev, u16 slot_time)
{
/* slot_time is in usec. */
- if (dev->phy.type != B43_PHYTYPE_G)
+ /* This test used to exit for all but a G PHY. */
+ if (b43_current_band(dev->wl) == IEEE80211_BAND_5GHZ)
return;
- b43_write16(dev, 0x684, 510 + slot_time);
- b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+ b43_write16(dev, B43_MMIO_IFSSLOT, 510 + slot_time);
+ /* Shared memory location 0x0010 is the slot time and should be
+ * set to slot_time; however, this register is initially 0 and changing
+ * the value adversely affects the transmit rate for BCM4311
+ * devices. Until this behavior is unterstood, delete this step
+ *
+ * b43_shm_write16(dev, B43_SHM_SHARED, 0x0010, slot_time);
+ */
}
static void b43_short_slot_timing_enable(struct b43_wldev *dev)
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 5461f10..d10bea6 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -2744,6 +2744,7 @@ int iwl_mac_config(struct ieee80211_hw *hw, u32 changed)
if ((le16_to_cpu(priv->staging_rxon.channel) != ch))
priv->staging_rxon.flags = 0;
+ iwl_set_rxon_ht(priv, ht_conf);
iwl_set_rxon_channel(priv, conf->channel);
iwl_set_flags_for_band(priv, conf->channel->band);
diff --git a/drivers/net/wireless/iwmc3200wifi/rx.c b/drivers/net/wireless/iwmc3200wifi/rx.c
index 3db3d8b..64d16fe 100644
--- a/drivers/net/wireless/iwmc3200wifi/rx.c
+++ b/drivers/net/wireless/iwmc3200wifi/rx.c
@@ -794,7 +794,7 @@ static int iwm_mlme_update_bss_table(struct iwm_priv *iwm, u8 *buf,
}
bss->bss = kzalloc(bss_len, GFP_KERNEL);
- if (!bss) {
+ if (!bss->bss) {
kfree(bss);
IWM_ERR(iwm, "Couldn't allocate bss\n");
return -ENOMEM;
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index bc5726d..7ba3052 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -65,6 +65,7 @@ static struct usb_device_id rtl8187_table[] __devinitdata = {
/* Sitecom */
{USB_DEVICE(0x0df6, 0x000d), .driver_info = DEVICE_RTL8187},
{USB_DEVICE(0x0df6, 0x0028), .driver_info = DEVICE_RTL8187B},
+ {USB_DEVICE(0x0df6, 0x0029), .driver_info = DEVICE_RTL8187B},
/* Sphairon Access Systems GmbH */
{USB_DEVICE(0x114B, 0x0150), .driver_info = DEVICE_RTL8187},
/* Dick Smith Electronics */
diff --git a/drivers/ssb/main.c b/drivers/ssb/main.c
index 5681ebe..03dfd27 100644
--- a/drivers/ssb/main.c
+++ b/drivers/ssb/main.c
@@ -494,8 +494,7 @@ static int ssb_devices_register(struct ssb_bus *bus)
#endif
break;
case SSB_BUSTYPE_SDIO:
-#ifdef CONFIG_SSB_SDIO
- sdev->irq = bus->host_sdio->dev.irq;
+#ifdef CONFIG_SSB_SDIOHOST
dev->parent = &bus->host_sdio->dev;
#endif
break;
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 1f2db64..22f0c2a 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -647,7 +647,7 @@ static void ieee80211_rx_mgmt_probe_req(struct ieee80211_sub_if_data *sdata,
}
if (pos[1] != 0 &&
(pos[1] != ifibss->ssid_len ||
- !memcmp(pos + 2, ifibss->ssid, ifibss->ssid_len))) {
+ memcmp(pos + 2, ifibss->ssid, ifibss->ssid_len))) {
/* Ignore ProbeReq for foreign SSID */
return;
}
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index f934c96..bc17cf7 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -439,6 +439,16 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
if (local->scan_req)
return -EBUSY;
+ if (req != local->int_scan_req &&
+ sdata->vif.type == NL80211_IFTYPE_STATION &&
+ !list_empty(&ifmgd->work_list)) {
+ /* actually wait for the work it's doing to finish/time out */
+ set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
+ local->scan_req = req;
+ local->scan_sdata = sdata;
+ return 0;
+ }
+
if (local->ops->hw_scan) {
u8 *ies;
@@ -463,14 +473,6 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
local->scan_req = req;
local->scan_sdata = sdata;
- if (req != local->int_scan_req &&
- sdata->vif.type == NL80211_IFTYPE_STATION &&
- !list_empty(&ifmgd->work_list)) {
- /* actually wait for the work it's doing to finish/time out */
- set_bit(IEEE80211_STA_REQ_SCAN, &ifmgd->request);
- return 0;
- }
-
if (local->ops->hw_scan)
__set_bit(SCAN_HW_SCANNING, &local->scanning);
else
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 0/3]: via-velocity: Fixes for locking issues
From: David Miller @ 2010-02-10 18:55 UTC (permalink / raw)
To: simon.kagstrom; +Cc: netdev, davej, ben
In-Reply-To: <20100210103358.41a45851@marrow.netinsight.se>
From: Simon Kagstrom <simon.kagstrom@netinsight.net>
Date: Wed, 10 Feb 2010 10:33:58 +0100
> Anyway, when you are happy with the patch series, I think it is 2.6.33
> material as the velocity driver would otherwise contain a regression
> compared to 2.6.32.
>
> Changes in the patch series:
>
> * Patch 1: Unchanged
>
> * Patch 2: Unchanged
>
> * Patch 3: Use spin_lock_irqsave in velocity_poll and remove
> spin_trylock from the interrupt handler.
Looks good, all applied to net-2.6, thanks!
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Fleming Andy-AFLEMING @ 2010-02-10 18:40 UTC (permalink / raw)
To: Grant Likely; +Cc: John Linn, devicetree-discuss, netdev, Scott Wood
In-Reply-To: <fa686aa41002101014s43682e3cra55854b82a40bb5f@mail.gmail.com>
On Feb 10, 2010, at 12:15, "Grant Likely" <grant.likely@secretlab.ca>
wrote:
> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com>
> wrote:
>>> -----Original Message-----
>>> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf
>>> Of Grant Likely
>>> Sent: Wednesday, February 10, 2010 9:44 AM
>>> To: John Linn; devicetree-discuss; netdev
>>> Subject: Re: phy address in the device tree, vs auto probing
>>>
>>> (cc'ing devicetree-discuss and netdev mailing lists)
>>>
>>> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@xilinx.com>
>>> wrote:
>>>> Hi Grant,
>>>>
>>>> I notice that the OF driver for the mdio bus is not doing auto
>>>> probing.
>>>>
>>>> As we start putting in the phy layer in the emac drivers, the
>>>> device
>>>> trees tend to have the phy address in them, but we're not sure we
>>>> really
>>>> like that.
>>>>
>>>> We really think that being able to let the kernel find the phy
>>>> address
>>>> is a big benefit, otherwise this is one other piece of info the
>>>> user has
>>>> to know and get right.
>>>>
>>>> Am I missing something here?
>>>
>>> No, you're not really missing something, but there is an inherent
>>> complexity in what you're wanting to do. Like i2c, MDIO is one of
>>> those busses that is hard to probe reliable. Some PHYs respond on
>>> more than one address, and there is no way to determine which MAC a
>>> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs
>>> with their own MDIO busses may still get wired to a PHY on a
>>> different
>>> bus.
>>>
>>> In the simple case where there is a one:one:one relationship between
>>> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>> correct? The question then must be asked; how does the kernel
>>> determine that it can use the simple case? Nobody has yet defined a
>>> way to describe that in the device tree; mostly because nobody has
>>> needed to yet.
>>>
>>> So, it is possible to do what you want, but you need a way to
>>> *explicitly* ask for that behaviour. ie, some way to indicate in a
>>> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>> probed for. I think this should only be an option when the MDIO bus
>>> has only one PHY. Come up with a proposal and post it to the
>>> devicetree-discuss mailing list.
>>
>> Here's a couple ideas. See what everyone thinks as I'm not stuck on
>> either.
>>
>> Thanks,
>> John
>>
>> 1. What if we just don't specific a phy address with a reg property
>> which would specify to auto probe it and find the phy as
>> illustrated below?
>>
>>
>> Ethernet_MAC: ethernet@81000000 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> phy-handle = <&phy0>;
>> mdio {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> phy0: phy@7 {
>> } ;
>> } ;
>>
>> 2. Or a special value (-1 or something not 0 - 31) in the phy
>> address that specifies to auto probe as illustrated below.
>> phy0: phy@7 {
>> reg = <-1>;
>> } ;
>
> I don't like abusing the reg property in this way. I wonder if a new
> empty property would be a better way to indicate this. Maybe
> "phy-probe-address;"? It would also be important to specify in the
> binding that only one phy node is allowed when phy-probe-address is
> used.
I don't think it's necessary that only one phy node is there. I don't
think the of mdio layer should set policy, here. Some drivers hard
code their addresses. Some drivers assume (foolishly, I think) that
the PHYs are in order. Many assume there's only one PHY. I think the
mdio driver should set policy, so of_mdio should just allow for PHYs
to be probed. I'm actually not sure that requires any changes. Quite
possibly this just means that of_mdio is not appropriate for such a
driver. The standard PHY code supports this sort of thing.
I don't think this can reasonably be done with of_phy_connect(),
because not every driver will want the same behavior.
If you can't have your bootloader modify the tree to have addresses
(and then it can do the probe however it wants, in a board-specific
way), then you could add some board code or mdio driver code which
modifies the device tree to have addresses.
Andy
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Mitch Bradley @ 2010-02-10 18:30 UTC (permalink / raw)
To: Grant Likely
Cc: John Linn, Scott Wood, netdev, devicetree-discuss, Andy Fleming
In-Reply-To: <fa686aa41002101014s43682e3cra55854b82a40bb5f@mail.gmail.com>
>
> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn@xilinx.com> wrote:
>
>>> >> -----Original Message-----
>>> >> From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On Behalf Of Grant Likely
>>> >> Sent: Wednesday, February 10, 2010 9:44 AM
>>> >> To: John Linn; devicetree-discuss; netdev
>>> >> Subject: Re: phy address in the device tree, vs auto probing
>>> >>
>>> >> (cc'ing devicetree-discuss and netdev mailing lists)
>>> >>
>>> >> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn@xilinx.com> wrote:
>>>
>>>> >> > Hi Grant,
>>>> >> >
>>>> >> > I notice that the OF driver for the mdio bus is not doing auto probing.
>>>> >> >
>>>> >> > As we start putting in the phy layer in the emac drivers, the device
>>>> >> > trees tend to have the phy address in them, but we're not sure we really
>>>> >> > like that.
>>>> >> >
>>>> >> > We really think that being able to let the kernel find the phy address
>>>> >> > is a big benefit, otherwise this is one other piece of info the user has
>>>> >> > to know and get right.
>>>> >> >
>>>> >> > Am I missing something here?
>>>>
>>> >>
>>> >> No, you're not really missing something, but there is an inherent
>>> >> complexity in what you're wanting to do. Like i2c, MDIO is one of
>>> >> those busses that is hard to probe reliable. Some PHYs respond on
>>> >> more than one address, and there is no way to determine which MAC a
>>> >> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs
>>> >> with their own MDIO busses may still get wired to a PHY on a different
>>> >> bus.
>>> >>
>>> >> In the simple case where there is a one:one:one relationship between
>>> >> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>> >> correct? The question then must be asked; how does the kernel
>>> >> determine that it can use the simple case? Nobody has yet defined a
>>> >> way to describe that in the device tree; mostly because nobody has
>>> >> needed to yet.
>>> >>
>>> >> So, it is possible to do what you want, but you need a way to
>>> >> *explicitly* ask for that behaviour. ie, some way to indicate in a
>>> >> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>> >> probed for. I think this should only be an option when the MDIO bus
>>> >> has only one PHY. Come up with a proposal and post it to the
>>> >> devicetree-discuss mailing list.
>>>
>> >
>> > Here's a couple ideas. See what everyone thinks as I'm not stuck on either.
>> >
>> > Thanks,
>> > John
>> >
>> > 1. What if we just don't specific a phy address with a reg property which would specify to auto probe it and find the phy as illustrated below?
>> >
>> >
>> > Ethernet_MAC: ethernet@81000000 {
>> > #address-cells = <1>;
>> > #size-cells = <1>;
>> > phy-handle = <&phy0>;
>> > mdio {
>> > #address-cells = <1>;
>> > #size-cells = <0>;
>> > phy0: phy@7 {
>> > } ;
>> > } ;
>> >
>> > 2. Or a special value (-1 or something not 0 - 31) in the phy address that specifies to auto probe as illustrated below.
>> > phy0: phy@7 {
>> > reg = <-1>;
>> > } ;
>>
>
> I don't like abusing the reg property in this way. I wonder if a new
> empty property would be a better way to indicate this. Maybe
> "phy-probe-address;"? It would also be important to specify in the
> binding that only one phy node is allowed when phy-probe-address is
> used.
>
> Also, without a known reg the 'phy@7' name is inaccurate. Drop the @7.
>
> Scott, Andy: any thoughts?
>
This case is somewhat similar to "wildcard nodes" on unprobed SCSI
buses, going all the way back to pre-1275 Open Boot. Since full probing
of a SCSI bus could take a really long time (spin-up delays etc), Open
Boot would usually create a bus node for the host controller and
populate it with a disk node and a tape node, neither of which had a reg
property. That meant that there was a good chance that you might find
such devices on that bus, but their specific SCSI bus addresses had not
yet been determined. In addition to those wildcard nodes, similar nodes
with extant reg properties could also appear, asserting the presence of
a known device at the given address. The node matching algorithm first
looks for an exact match with a reg property, and failing that, looks
for a wildcard match.
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: M. Warner Losh @ 2010-02-10 18:37 UTC (permalink / raw)
To: scottwood-KZfg59tc24xl57MIdRCFDg
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
afleming-KZfg59tc24xl57MIdRCFDg
In-Reply-To: <4B72FAB2.5000804-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
In message: <4B72FAB2.5000804-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org> writes:
: Grant Likely wrote:
: >> 1. What if we just don't specific a phy address with a reg property
: >> which would specify to auto probe it and find the phy as illustrated
: >> below?
: >>
: >>
: >> Ethernet_MAC: ethernet@81000000 {
: >> #address-cells = <1>;
: >> #size-cells = <1>;
: >> phy-handle = <&phy0>;
: >> mdio {
: >> #address-cells = <1>;
: >> #size-cells = <0>;
: >> phy0: phy@7 {
: >> } ;
: >> } ;
: >>
: >> 2. Or a special value (-1 or something not 0 - 31) in the phy address
: >> that specifies to auto probe as illustrated below.
: >> phy0: phy@7 {
: >> reg = <-1>;
: >> } ;
: > I don't like abusing the reg property in this way. I wonder if a new
: > empty property would be a better way to indicate this. Maybe
: > "phy-probe-address;"? It would also be important to specify in the
: > binding that only one phy node is allowed when phy-probe-address is
: > used.
: > Also, without a known reg the 'phy@7' name is inaccurate. Drop the
: > @7.
: > Scott, Andy: any thoughts?
:
: I'm not fond of the -1. I'd prefer the explicit phy-probe-address
: property, though I don't mind too much using the absence of reg.
There are times that you'd want a list of PHY addresses to use. This
suggests a bitmask, but I don't know if they are common enough to
warrant the extra burden on the usual case...
Warner
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Mitch Bradley @ 2010-02-10 18:35 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, netdev, devicetree-discuss, Andy Fleming
In-Reply-To: <4B72FB38.7080909-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
>
>>
>> On Wed, Feb 10, 2010 at 9:52 AM, John Linn <John.Linn-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>
>>>> >> -----Original Message-----
>>>> >> From: glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org [mailto:glikely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org] On
>>>> Behalf Of Grant Likely
>>>> >> Sent: Wednesday, February 10, 2010 9:44 AM
>>>> >> To: John Linn; devicetree-discuss; netdev
>>>> >> Subject: Re: phy address in the device tree, vs auto probing
>>>> >>
>>>> >> (cc'ing devicetree-discuss and netdev mailing lists)
>>>> >>
>>>> >> On Tue, Feb 9, 2010 at 4:23 PM, John Linn <John.Linn-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>>> wrote:
>>>>
>>>>> >> > Hi Grant,
>>>>> >> >
>>>>> >> > I notice that the OF driver for the mdio bus is not doing
>>>>> auto probing.
>>>>> >> >
>>>>> >> > As we start putting in the phy layer in the emac drivers, the
>>>>> device
>>>>> >> > trees tend to have the phy address in them, but we're not
>>>>> sure we really
>>>>> >> > like that.
>>>>> >> >
>>>>> >> > We really think that being able to let the kernel find the
>>>>> phy address
>>>>> >> > is a big benefit, otherwise this is one other piece of info
>>>>> the user has
>>>>> >> > to know and get right.
>>>>> >> >
>>>>> >> > Am I missing something here?
>>>>>
>>>> >>
>>>> >> No, you're not really missing something, but there is an inherent
>>>> >> complexity in what you're wanting to do. Like i2c, MDIO is one of
>>>> >> those busses that is hard to probe reliable. Some PHYs respond on
>>>> >> more than one address, and there is no way to determine which MAC a
>>>> >> PHY is wired up to. Many PHYs can live on a single MDIO bus. MACs
>>>> >> with their own MDIO busses may still get wired to a PHY on a
>>>> different
>>>> >> bus.
>>>> >>
>>>> >> In the simple case where there is a one:one:one relationship
>>>> between
>>>> >> MAC, MDIO bus and PHY, then it should be okay to probe the PHY,
>>>> >> correct? The question then must be asked; how does the kernel
>>>> >> determine that it can use the simple case? Nobody has yet
>>>> defined a
>>>> >> way to describe that in the device tree; mostly because nobody has
>>>> >> needed to yet.
>>>> >>
>>>> >> So, it is possible to do what you want, but you need a way to
>>>> >> *explicitly* ask for that behaviour. ie, some way to indicate in a
>>>> >> MAC node which MDIO bus the phy is on, and that the phy needs to be
>>>> >> probed for. I think this should only be an option when the MDIO
>>>> bus
>>>> >> has only one PHY. Come up with a proposal and post it to the
>>>> >> devicetree-discuss mailing list.
>>>>
>>> >
>>> > Here's a couple ideas. See what everyone thinks as I'm not stuck
>>> on either.
>>> >
>>> > Thanks,
>>> > John
>>> >
>>> > 1. What if we just don't specific a phy address with a reg
>>> property which would specify to auto probe it and find the phy as
>>> illustrated below?
>>> >
>>> >
>>> > Ethernet_MAC: ethernet@81000000 {
>>> > #address-cells = <1>;
>>> > #size-cells = <1>;
>>> > phy-handle = <&phy0>;
>>> > mdio {
>>> > #address-cells = <1>;
>>> > #size-cells = <0>;
>>> > phy0: phy@7 {
>>> > } ;
>>> > } ;
>>> >
>>> > 2. Or a special value (-1 or something not 0 - 31) in the phy
>>> address that specifies to auto probe as illustrated below.
>>> > phy0: phy@7 {
>>> > reg = <-1>;
>>> > } ;
>>>
>>
>> I don't like abusing the reg property in this way. I wonder if a new
>> empty property would be a better way to indicate this. Maybe
>> "phy-probe-address;"? It would also be important to specify in the
>> binding that only one phy node is allowed when phy-probe-address is
>> used.
>>
>> Also, without a known reg the 'phy@7' name is inaccurate. Drop the @7.
>>
>> Scott, Andy: any thoughts?
>>
>
> This case is somewhat similar to "wildcard nodes" on unprobed SCSI
> buses, going all the way back to pre-1275 Open Boot. Since full
> probing of a SCSI bus could take a really long time (spin-up delays
> etc), Open Boot would usually create a bus node for the host
> controller and populate it with a disk node and a tape node, neither
> of which had a reg property. That meant that there was a good chance
> that you might find such devices on that bus, but their specific SCSI
> bus addresses had not yet been determined. In addition to those
> wildcard nodes, similar nodes with extant reg properties could also
> appear, asserting the presence of a known device at the given
> address. The node matching algorithm first looks for an exact match
> with a reg property, and failing that, looks for a wildcard match.
>
FYI, wildcard matching is defined in section 4.3.3 clause (b) and
section 4.3.5 of IEEE 1275-1994.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox