* Re: Note: Atheros ethernet part of compat-wireless too
From: Luis R. Rodriguez @ 2010-02-10 18:16 UTC (permalink / raw)
To: Tony Espy; +Cc: Ubuntu Kernel Team, netdev
In-Reply-To: <4B686056.7090405@canonical.com>
On Tue, Feb 2, 2010 at 9:26 AM, Tony Espy <espy@canonical.com> wrote:
> Luis R. Rodriguez wrote:
>>
>> I wanted to let you know I threw in the Atheros ethernet drivers as
>> part of compat-wireless.
>
> Luis --
>
> Does this include support for the Atheros AR8152 PCI-E fast ethernet
> adapter? Also, what's the lead time for this to land in a "stable" release?
Figured I'd give you the heads up that the AR8152 is not supported
upstream yet. I just got a tarball of the driver that supports this
and AR8151. Here's our current upstream support status table:
Driver Model-name vendor:device Type
atl1c AR8131 1969:1063 Gigabit Ethernet
atl1c AR8132 1969:1062 Fast Ethernet
atl1 L1 1969:1048 Gigabit Ethernet
atl2 L2 1969:2048 Fast Ethernet
atl1e AR8121/AR8113/AR8114 1969:1026 Gigabit/Fast Ethernet(driver
check one internal register to
see if support gigabit)
atl1c AR8151(v1.0) 1969:1073 Gigabit Ethernet(not support
in kernel yet)
atl1c AR8152(v1.1) 1969:2060 Fast Ethernet(not support
in kernel yet)
atl1c AR8152(v2.0) 1969:2062 Fast Ethernet(not support
in kernel yet)
I just updated the PCI ID database accordingly. The driver patches for
atl1c might be easy, will take a quick look. FWIW the tarball I will
be looking at in a few moments is
http://kernel.org/pub/linux/kernel/people/mcgrof/ethernet/AR81Family-linux-v1.0.1.6.tar.bz2
Luis
^ permalink raw reply
* RX performance degradation with e1000e in Linux 2.6.31 / F12
From: Kelvin Ku @ 2010-02-10 18:24 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev, users
[-- Attachment #1: Type: text/plain, Size: 3144 bytes --]
After upgrading from Linux 2.6.30 (Fedora Core 11) to 2.6.31 (F12), I am
experiencing significant packet loss on an Intel 82574L NIC running on the
e1000e driver. I was not experiencing this with kernel 2.6.30. I notice 2.6.30
uses e1000e version 0.3.3.4-k4 whereas 2.6.31 uses version 1.0.2-k2.
I have tried setting IntMode to 0, 1, and 2 and InterruptThrottleRate to 0, 1,
3 (the default), 1000, 5000, 10000, and 100000. I've also tried booting with
the "noapic" kernel parameter.
I am testing with ttcp, sending 100000 1450 byte UDP packets at about 910 Mbps.
With InterruptThrottleRate at 1, 3, 5000, or 10000, I see the following
behaviour on the receiver side:
ttcp -u -4 -l 1450 -s -fm -r
ttcp-r: buflen=1450, nbuf=2048, align=16384/0, port=5001 udp
ttcp-r: socket
ttcp-r: 98486900 bytes in 1.22 real seconds = 617.22 Mbit/sec +++
ttcp-r: 67924 I/O calls, msec/call = 0.02, calls/sec = 55794.64
ttcp-r: 0.0user 0.0sys 0:01real 0% 0i+0d 0maxrss 0+0pf 4963+3csw
So in total (145000000 - 98486900)/1450 = 32078 out of 100000 packets were
dropped, or about 32%.
This is the difference between /proc/interrupts (the change in each counter)
before and after the test. lan0 is the interface being tested. Notice that
there are a significant number of interrupts on the "sequence error" interrupt;
I'm guessing that's 57:
55: 0 0 0 8603 PCI-MSI-edge
56: 0 0 0 25 PCI-MSI-edge Q�����V
57: 4868 0 0 0 PCI-MSI-edge lan0
67: 0 0 2 0 PCI-MSI-edge ��������@�
68: 0 0 0 0 PCI-MSI-edge
69: 0 0 0 0 PCI-MSI-edge lan1
This is the difference between the output from 'ethtool -S lan0' before and
after the test; only fields which changed are shown:
: rx_broadcast: 585730 - 581046 = 4684
: rx_bytes: 931068459 - 822452567 = 108615892
: rx_csum_offload_good: 650149 - 577551 = 72598
: rx_long_byte_count: 931068459 - 822452567 = 108615892
: rx_missed_errors: 31003 - 6 = 30997
: rx_packets: 655692 - 583072 = 72620
: rx_smbus: 5784 - 5763 = 21
: tx_broadcast: 972 - 969 = 3
: tx_bytes: 388453 - 385439 = 3014
: tx_packets: 3025 - 3012 = 13
Notice the large rx_missed_errors count which indicates NIC FIFO or PCI bus
exhaustion.
If I disable interrupt throttling or set the limit very high, e.g., 100000, the
same test generates about 65,000 data interrupts and 93,000 error interrupts
and rx_missed_errors increases by 34,000. This suggests to me that the NIC is
attempting to raise an interrupt for every packet received.
An Intel 82576 NIC in the same system, running on the igb driver, is performing
OK under 2.6.31 (0 to 0.1% packet loss). For comparison, the same UDP test
generates about 6000 interrupts on the 82576.
dmesg, dmidecode, ethtool, lspci, 'netstat -s', and /proc/interrupts output is
attached.
N.B. I tried removing the 82576 NIC from the system before testing as well; no
change.
- Kelvin
[-- Attachment #2: testhost.dmesg.gz --]
[-- Type: application/x-gzip, Size: 12360 bytes --]
[-- Attachment #3: testhost.dmidecode.gz --]
[-- Type: application/x-gzip, Size: 4371 bytes --]
[-- Attachment #4: testhost.ethtool.gz --]
[-- Type: application/x-gzip, Size: 1075 bytes --]
[-- Attachment #5: testhost.lspci.gz --]
[-- Type: application/x-gzip, Size: 5162 bytes --]
[-- Attachment #6: testhost.netstat.gz --]
[-- Type: application/x-gzip, Size: 679 bytes --]
[-- Attachment #7: testhost.proc-interrupts.gz --]
[-- Type: application/x-gzip, Size: 660 bytes --]
[-- Attachment #8: Type: text/plain, Size: 231 bytes --]
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
^ permalink raw reply
* Re: phy address in the device tree, vs auto probing
From: Scott Wood @ 2010-02-10 18:28 UTC (permalink / raw)
To: Grant Likely; +Cc: netdev, devicetree-discuss, Andy Fleming
In-Reply-To: <fa686aa41002101014s43682e3cra55854b82a40bb5f-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
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.
-Scott
^ permalink raw reply
* Corrupt /proc/interrupts with e1000e
From: Kelvin Ku @ 2010-02-10 18:31 UTC (permalink / raw)
To: e1000-devel; +Cc: netdev, users
I see the following in /proc/interrupts
55: 0 0 0 338331 PCI-MSI-edge lan0-rx-0
56: 0 0 0 2664 PCI-MSI-edge lan0-tx-0
57: 47230 0 0 0 PCI-MSI-edge lan0
58: 427 0 0 0 PCI-MSI-edge �
59: 0 277 0 0 PCI-MSI-edge �����������
60: 0 4 0 0 PCI-MSI-edge lan1
Notice the corrupt entries for IRQs 58 and 59. Sometimes 55 and 56 are corrupt as well. Any idea why this is happening? I am running Fedora Core 12.
$ sudo ethtool -i lan0
driver: e1000e
version: 1.0.2-k2
firmware-version: 1.8-0
bus-info: 0000:06:00.0
$ uname -r
2.6.31.12-174.2.3.fc12.x86_64
This is the NIC:
$ lspci
06:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
07:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
- Kelvin
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
^ 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
* 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: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: 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: [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
* 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
* [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
* 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
* 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: 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: 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: [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: 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: 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: [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: [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: 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: 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: 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: [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: 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
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